Re: [Patch 3/3] Tracing/ftrace: Replace none tracer by nop tracer

[Ingo Molnar]

* Frédéric Weisbecker <fweisbec@xxxxxxxxx> wrote:

> Replace "none" tracer by the recently created "nop" tracer. Both are 
> pretty similar except that nop accepts TRACE_PRINT or TRACE_SPECIAL 
> entries. And as a consequence, changing the size of the ring buffer 
> now requires that tracing has already been disabled.

btw., if people are interested in new tracers, it would be useful to 
have an initcall tracer which can capture boot delays and schedule 
events from bootup. -tip has the 'fastboot' feature topic which could 
make use of such a tracer.

Right now fastboot profiling works like this: it (abu-)uses the 
initcall_debug boot parameter to get such special printouts in 
init/main.c:

                printk("initcall %pF returned %d after %Ld msecs\n", fn,
                        result, (unsigned long long) delta.tv64 >> 20);

and relies on CONFIG_PRINTK_TIME to get event timestamps. Then, after 
bootup, scripts/bootgraph.pl can be used to draw a graph of bootup 
dependencies and timings.

the efficiency of this mechanism could be extended significantly via an 
ftrace/fastboot plugin: it would allow non-initcall delays to be traced, 
plus the _reason_ for the delays as well. Stackframe tracing could be 
enabled by default (see 'stacktrace' / TRACE_ITER_STACKTRACE / 
__trace_stack() in kernel/tracing/trace.c - not to be confused with the 
stack-footprint tracer ftrace/stacktrace), and context-switch events 
could be / should be traced as well.

the ideal workflow would be like this: developers optimizing fastboot 
details would enable a single kernel option: CONFIG_TRACE_BOOT, and that 
would be an 'all in one' switch. Tracing would occur by default (no 
extra boot parameters), and /debug/tracing/trace would have output 
suitable for scripts/bootgraph.pl parsing.

(at least) one architectural detail that needs to be solved here is the 
fact that ftrace is initialized via an initcall right now. It should 
probably be initialized via an early-initcall instead.

Hm?

	Ingo
--
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/