Messages in this thread | | | Date | Mon, 22 Sep 2008 14:30:47 +0200 | From | "Frédéric Weisbecker" <> | Subject | Re: [Patch 3/3] Tracing/ftrace: Replace none tracer by nop tracer |
| |
2008/9/22 Ingo Molnar <mingo@elte.hu>: > 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 >
Sounds really interesting. I will try to write this tracer in next days. But first I will try to solve this initcall problem...
(Sorry Ingo, I forgot to cc LKML)
Frédéric. -- 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/
| |