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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 22 Sep 2008 14:30:47 +0200
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Linux Kernel" <linux-kernel@...r.kernel.org>,
	"Steven Rostedt" <rostedt@...dmis.org>,
	"Steven Noonan" <steven@...inklabs.net>,
	"Arjan van de Ven" <arjan@...radead.org>
Subject: Re: [Patch 3/3] Tracing/ftrace: Replace none tracer by nop tracer

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