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

* Peter Zijlstra <a.p.zijlstra@chello.nl> 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
kernel.

Ingo


\
 
 \ /
  Last update: 2008-04-15 15:21    [from the cache]
©2003-2011 Jasper Spaans