Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers

[Peter Zijlstra <peterz at infradead dot org>]

On Sat, 2008-06-21 at 11:07 -0400, Steven Rostedt wrote:
> On Sat, 21 Jun 2008, Frank Ch. Eigler wrote:
> > Steven Rostedt <rostedt@goodmis.org> writes:

> > > It also just looks like a debug session instead of a trace marker.
> >
> > Why do you think the difference between those is profound?
> 
> Not that profound but I do find:
> 
>   trace_sched_switch(prev, next);
> 
> much nicer to look at than
> 
>   trace_mark("%p %p", prev, next);
> 
> 
> The trace_sched_switch seems a bit more informative with a simple glance
> than the trace_mark.

I think what Frank refers to here is why not scatter the kernel code
with trace_mark()s on every conceivable location like you do with
printk-style debugging. Those trace marks might help out when
$customer's kernel goes splat and you don't want to provide him with a
custom kernel.

I do think we must make a clear distinction between these cases because:

 1) tracers provide a kernel<->user interface - and whilst we don't have
a stable in-kernel API/ABI we are anal about the kernel/user boundary.
Andrew also greatly worries about this aspect.

 2) it highly uglyfies the code, Frank doesn't need to maintain it, so
its easy for him to say. But IMHO its much harder to read code that is
littered with debug statements that it is to read regular code.

 3) it bloats the kernel,.. while it may not be fast path bloat, all
that marker stuff does go somewhere.


So, while I see the value of 'stable' mark sites for 'stable' events,
I'm dead-set against littering the kernel with markers just because we
can, and hoping they might some day be useful for someone.