Messages in this thread | | | Date | Tue, 15 Apr 2008 15:17:44 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |