[lkml]   [2008]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 1/2] Marker probes in futex.c

    * Peter Zijlstra <> wrote:

    > > Because we extract the field names and types, we can create tracer
    > > plugins that would hook on field names rather than expect a specific
    > > number of fields and fixed field types. It makes it possible to
    > > tolerate missing fields pretty easily. But yes, tracer tools might
    > > have to be adapted to internal kernel changes, since they must
    > > follow kernel structure changes. However, staying as close as
    > > possible to a canonical representation of event fields, staying far
    > > from the specific implemetation, would help to lessen the
    > > inter-dependency. On the other hand, it would probably hurt trace
    > > compactness and efficiency.
    > See, these tracer tools are my nightmare as member of an enterprise
    > linux team. They'll make an already hard job even harder, no thanks!

    i'm clearly NAK-ing all futex trace hooks until the true impact of the
    whole marker facility is better understood. I've tried them for the
    scheduler and they were a clear failure: too bloated and too persistent.

    but more importantly, as things stand today i've yet to see a _any_
    bugreport where these 'tracer' tools that are being referred to were
    actually used in the field to fix something. The latency tracers (and
    the other tracer variants in -rt) on the other hand have a documented
    track record of being useful in fixing bugs and instrumenting the


     \ /
      Last update: 2008-04-15 15:21    [W:0.022 / U:2.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site