Re: [GIT PULL] x86/cpu changes for v2.6.34

[Steven Rostedt]

On Mon, 2010-03-01 at 14:17 +0100, Frederic Weisbecker wrote:
> On Mon, Mar 01, 2010 at 09:00:58AM +0100, Ingo Molnar wrote:
> > Weird. It seems to be around multiples of .8: 0.8, 1.6, 2.4, with some extra 
> > overhead.
> > 
> > Almost as if some calibration routine or some other busy-loop misses the train 
> > occasionally.
> > 
> > The way i'd go about debugging this is to narrow down the approximate place 
> > the slowdown happens, then enable CONFIG_FUNCTION_TRACER (and disable 
> > CONFIG_DYNAMIC_FTRACE=y, to not have to deal with the dynamic patching 
> > aspects), and do a single-shot tracing session of only that section, on only 
> > one CPU:
> > 
> > 	if (smp_processor_id() == 7)
> > 		ftrace_enabled = 1;
> > 
> > 	... bootup sequence ...
> > 
> > 	if (smp_processor_id() == 7)
> > 		ftrace_enabled = 0;
> > 
> > And recover the resulting trace from /debug/tracing/trace - it should have the reason
> > in it plain and simple.
> > 
> > ( Unfortunately i'm not 100% sure that setting ftrace_enabled to 1 is enough. 
> >   I asked for a simple ad-hoc enable/disable function tracing mechanism _ages_ 
> >   ago - Steve, Frederic, what happened to that? ftrace_start()/stop() does not 
> >   seem to allow that. )
> 

Setting ftrace_enabled = 0 should stop the function tracer, but may not
stop the function graph tracer.

> 
> 
> I don't remember such request. But that would be useful indeed.
> We could simply pair the setting of an early tracer with tracing
> disabled and then manually delimit the places to trace with
> tracing_on/tracing_off().

It's best to use tracing_off() and tracing_on() for such things.

> 
> Whatever.
> 
> For now what you can do is setting the function_graph tracer
> on bootup:
> 
> 	ftrace=function_graph
> 
> and call ftrace_graph_stop() in the place you want the trace

tracing_off() is the best API for this. Although you still have the
overhead of the tracer. But you can just
 echo nop > /debug/tracing/current_tracer
to remove the overhead after bootup.

-- Steve

> to finish (you could use ftrace_graph_filter= to delimit
> the function tracing window, but that won't work without
> dynamic tracing, neither with __init functions).
> 
> So, after the boot you can look at /debug/tracing/per_cpu/cpu7/trace
> and the end of the trace should contain what you want.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/