From: Ingo Molnar <mingo@elte.hu>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Steven Noonan <steven@uplinklabs.net>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [Patch 3/3] Tracing/ftrace: Replace none tracer by nop tracer
Date: Mon, 22 Sep 2008 11:43:58 +0200 [thread overview]
Message-ID: <20080922094358.GB17258@elte.hu> (raw)
In-Reply-To: <48D68F7E.5020609@gmail.com>
* 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
next prev parent reply other threads:[~2008-09-22 9:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-21 18:16 Frédéric Weisbecker
2008-09-22 9:43 ` Ingo Molnar [this message]
2008-09-22 12:30 ` Frédéric Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080922094358.GB17258@elte.hu \
--to=mingo@elte.hu \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=steven@uplinklabs.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®