From: Chase Douglas <chase.douglas@canonical.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Tracing configuration review
Date: Tue, 25 May 2010 15:31:46 -0400 [thread overview]
Message-ID: <1274815906.9757.83.camel@cndougla-ubuntu> (raw)
Hi all,
I'm going through our Ubuntu kernel configuration for our next release
to ensure we have all the trace options enabled that may be useful. I
have a few questions about what tracer options we should have enabled.
Our guiding principle in regards to these options is: if an option can
be turned on and has no performance impact unless explicitly enabled on
the kernel command line or at runtime, we are happy to enable it.
Secondarily, we don't want to enable options that are headed for
deprecation.
The following options are what I am looking to set for our x86
configurations. I've only included those that I am not 100% sure of.
Comments are what I could gather from documentation and Kconfig, but
they may not be accurate:
# CONFIG_IRQSOFF_TRACER is not set (performance impact by default)
# CONFIG_SYSPROF_TRACER is not set (don't know much about this)
# CONFIG_SCHED_TRACER is not set (headed for deprecation?)
CONFIG_FTRACE_SYSCALLS=y (no performance impact by default)
CONFIG_BOOT_TRACER=y (no performance impact by default)
CONFIG_KSYM_TRACER=y (no performance impact by default)
# CONFIG_STACK_TRACER is not set (Kconfig says N if unsure)
# CONFIG_KMEMTRACE is not set (Kconfig says N if unsure)
CONFIG_WORKQUEUE_TRACER=y (no performance impact by default)
Lastly, what options are safe for performance when
HAVE_DYNAMIC_FTRACE=n, like on our ARM kernels. It is not clear to me
through what's in Documentation/trace/* and the Kconfig entries what
options could cause a performance decrease due to the inability to
dynamically enable and disable tracing at runtime.
Thanks,
-- Chase
next reply other threads:[~2010-05-25 19:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 19:31 Chase Douglas [this message]
2010-05-25 19:46 ` Tracing configuration review Steven Rostedt
2010-05-25 19:58 ` Chase Douglas
2010-05-25 20:20 ` Frederic Weisbecker
2010-05-25 20:17 ` Frederic Weisbecker
2010-05-25 22:01 ` Steven Rostedt
2010-05-25 23:13 ` Frederic Weisbecker
2010-05-26 10:57 ` [Patch] tracing: remove boot tracer Américo Wang
2010-05-26 15:49 ` Frederic Weisbecker
2010-05-25 20:13 ` Tracing configuration review Frederic Weisbecker
2010-05-25 21:09 ` Chase Douglas
2010-05-25 23:06 ` Frederic Weisbecker
2010-05-27 11:20 ` K.Prasad
2010-05-27 22:15 ` Frederic Weisbecker
2010-06-08 17:35 ` Randy Dunlap
2010-06-08 22:00 ` Chase Douglas
2010-06-11 21:51 ` Randy Dunlap
2010-06-14 2:41 ` Chase Douglas
2010-05-26 6:19 ` Pekka Enberg
2010-05-26 7:20 ` Li Zefan
2010-05-26 7:44 ` Pekka Enberg
2010-05-26 8:42 ` Eduard - Gabriel Munteanu
2010-05-26 9:12 ` 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=1274815906.9757.83.camel@cndougla-ubuntu \
--to=chase.douglas@canonical.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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;
as well as URLs for NNTP newsgroup(s).