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

[Frederic Weisbecker <fweisbec@gmail.com>]

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. )



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().

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
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.