From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>,
Arjan van de Ven <arjan@infradead.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing/fastboot: document the need of initcall_debug
Date: Mon, 29 Jun 2009 21:39:18 +0200 [thread overview]
Message-ID: <20090629193918.GA31577@elte.hu> (raw)
In-Reply-To: <20090629111901.GB6265@nowhere>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Mon, Jun 29, 2009 at 11:14:22AM +0200, Ingo Molnar wrote:
> >
> > * Li Zefan <lizf@cn.fujitsu.com> wrote:
> >
> > > Ingo Molnar wrote:
> > > > * Li Zefan <lizf@cn.fujitsu.com> wrote:
> > > >
> > > >> To use boot tracer, one should pass initcall_debug as well as
> > > >> ftrace=initcall to the command line.
> > > >
> > > > I think both should be auto-enabled if BOOT_TRACER is enabled, for
> > > > ease of use - agreed?
> > >
> > > If both are auto-enabled, we'll always do boot tracing. But we
> > > want BOOT_TRACER to be enabled and only enable boot tracing when
> > > it's needed.
> > >
> > > But maybe we can make ftrace=initcall implies initcall_debug=1?
> >
> > That's reasonable indeed.
> >
> > Ingo
>
> Yeah.
>
> Although I wonder if this tracer is still useful. It was first
> written to debug fastboot, to get more than the initcall_debug
> output, ie: the scheduling events but now I guess the latter is
> not useful anymore. And using initcall_debug already does the job
> of printing the initcall events.
>
> What do you think?
Arjan is/was a frequent user of it. I think some neat stuff came out
of it: the trace can be fed into sysprof/ftrace and can be
visualized.
If we remove it we should first provide a replacement perfcounters
feature for it. Something like a special sw counter that 'buffers'
its events and so can be enabled during early bootup by the kernel,
and disabled once init is executed. If user-space creates a counter
on that event then it gets to read all the boot-time events in a
stream.
Or something like that. That would integrate the boot tracer
functionality into perfcounters tooling. We could do a 'perf report'
display of boot delays for example, and other neat stuff. Sounds
extremely useful and more usable than the boot tracer because this
special 'boot delays' event would always be there and can be used by
the regular 'perf' tooling to inspect bootup properties.
Ingo
next prev parent reply other threads:[~2009-06-29 19:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 7:55 [PATCH] tracing/fastboot: document the need of initcall_debug Li Zefan
2009-06-29 8:21 ` Ingo Molnar
2009-06-29 9:01 ` Li Zefan
2009-06-29 9:14 ` Ingo Molnar
2009-06-29 11:19 ` Frederic Weisbecker
2009-06-29 19:39 ` Ingo Molnar [this message]
2009-06-29 8:24 ` [tip:tracing/urgent] tracing/fastboot: Document " tip-bot for Li Zefan
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=20090629193918.GA31577@elte.hu \
--to=mingo@elte.hu \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=rostedt@goodmis.org \
/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