Messages in this thread | | | Date | Mon, 22 Sep 2008 11:43:58 +0200 | From | Ingo Molnar <> | Subject | Re: [Patch 3/3] Tracing/ftrace: Replace none tracer by nop tracer |
| |
* Frédéric Weisbecker <fweisbec@gmail.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |