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

From: Frederic Weisbecker
Date: Mon Mar 01 2010 - 08:17:15 EST

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


For now what you can do is setting the function_graph tracer
on bootup:


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at