LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
Abhishek Sagar <sagar.abhishek@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 08/13 v2] ftrace: do not trace init sections
Date: Thu, 23 Oct 2008 12:05:53 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.1.10.0810231202310.1765@gandalf.stny.rr.com> (raw)
In-Reply-To: <49008A9B.8040905@siemens.com>
On Thu, 23 Oct 2008, Jan Kiszka wrote:
>
> >From my POV - I'm using mcount tracing for a few years now -, the thing
> about this is gaining a complete overview of what happens at function
> level, which code paths were taken (at that level). Each bit of
> information you (have to) drop can harm here, even more if they come in
> larger chunks like in this case.
Then you should be happy :-)
I removed the notrace to those sections. Although there is already a
notrace on the __init. We probably should remove it. The recordmcount.pl
does not add tracing to these functions. If you want tracing of these
functions, you will need to use the static ftrace tracer (!DYNAMIC_FTRACE)
>
> I don't know if this feature is already considered for / part of
> mainline, but oops backtraces based on mcount instrumentation used to be
> quite helpful for me to understand the wider context of several faults.
> The more you have to mask out of this picture, the harder it gets to
> match the trace to your model of the kernel activities. At least you
> have to know more in advance about the limitation of the tracer...
The ftrace buffer can be dumped out on oops. I'm not sure if it is always
on. If it is, I need to make it default off and add a command line and
sysctl to turn it on. Otherwise, we will have people complaining about the
extra output to the console on oops.
-- Steve
next prev parent reply other threads:[~2008-10-23 16:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 21:27 [PATCH 00/13 v2] ftrace: clean ups and fixes Steven Rostedt
2008-10-22 21:27 ` [PATCH 01/13 v2] ftrace: handle generic arch calls Steven Rostedt
2008-10-27 15:35 ` Ingo Molnar
2008-10-22 21:27 ` [PATCH 02/13 v2] ftrace: dynamic ftrace process only text section Steven Rostedt
2008-10-22 21:27 ` [PATCH 03/13 v2] ftrace: return error on failed modified text Steven Rostedt
2008-10-22 21:27 ` [PATCH 04/13 v2] ftrace: comment arch ftrace code Steven Rostedt
2008-10-22 21:27 ` [PATCH 05/13 v2] ftrace: use probe_kernel Steven Rostedt
2008-10-22 21:27 ` [PATCH 06/13 v2] ftrace: only have ftrace_kill atomic Steven Rostedt
2008-10-22 21:27 ` [PATCH 07/13 v2] ftrace: add ftrace warn on to disable ftrace Steven Rostedt
2008-10-22 21:27 ` [PATCH 08/13 v2] ftrace: do not trace init sections Steven Rostedt
2008-10-23 11:15 ` Jan Kiszka
2008-10-23 11:36 ` Steven Rostedt
2008-10-23 14:30 ` Jan Kiszka
2008-10-23 16:05 ` Steven Rostedt [this message]
2008-10-23 16:40 ` Ingo Molnar
2008-10-23 16:51 ` Steven Rostedt
2008-10-22 21:27 ` [PATCH 09/13 v2] ftrace: disable dynamic ftrace for all archs that use daemon Steven Rostedt
2008-10-22 21:27 ` [PATCH 10/13 v2] ftrace: remove daemon Steven Rostedt
2008-10-22 21:27 ` [PATCH 11/13 v2] ftrace: remove mcount set Steven Rostedt
2008-10-22 21:27 ` [PATCH 12/13 v2] ftrace: remove ftrace hash Steven Rostedt
2008-10-22 21:27 ` [PATCH 13/13 v2] ftrace: remove notrace from arch ftrace file Steven Rostedt
2008-10-23 9:29 ` [PATCH 00/13 v2] ftrace: clean ups and fixes Wenji Huang
2008-10-23 10:49 ` Steven Rostedt
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=alpine.DEB.1.10.0810231202310.1765@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=fweisbec@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sagar.abhishek@gmail.com \
--cc=srostedt@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--subject='Re: [PATCH 08/13 v2] ftrace: do not trace init sections' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).