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

[Frédéric Weisbecker]

2008/9/22 Ingo Molnar <mingo@xxxxxxx>:
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/