mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Tracing configuration review
Date: Tue, 25 May 2010 15:46:08 -0400	[thread overview]
Message-ID: <1274816768.22648.220.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <1274815906.9757.83.camel@cndougla-ubuntu>

On Tue, 2010-05-25 at 15:31 -0400, Chase Douglas wrote:
> 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)

Correct, keep that off.

> # CONFIG_SYSPROF_TRACER is not set (don't know much about this)

Neither do I ;-)


> # CONFIG_SCHED_TRACER is not set (headed for deprecation?)

Although it is headed for deprecation, I think it still gets set by
other tracers, since it has the code to initiate the comm reader.

> CONFIG_FTRACE_SYSCALLS=y (no performance impact by default)

Correct

> CONFIG_BOOT_TRACER=y (no performance impact by default)

But this tracer is pretty useless. It gives no more information than
debug_initcalls.

> CONFIG_KSYM_TRACER=y (no performance impact by default)

Yep

> # CONFIG_STACK_TRACER is not set (Kconfig says N if unsure)

I would set this if you already have the function tracer. It gives no
more overhead than that, and it is very useful.

> # CONFIG_KMEMTRACE is not set (Kconfig says N if unsure)

Don't know.

> 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.

HAVE_DYNAMIC_FTRACE affects the function tracer. If you do not have
that, then do not enable FUNCTION_TRACER or anything that depends on it.

Also note, FUNCTION_TRACER depends on FRAME_POINTERS. Your millage may
vary with that. If you already have FRAME_POINTERS on, and the arch
supports DYNAMIC_FTRACE, then its fine to have FUNCTION_TRACER and all
those that are built on top (STACK_TRACER, FUNCTION_GRAPH, etc)

-- Steve



  reply	other threads:[~2010-05-25 19:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-25 19:31 Chase Douglas
2010-05-25 19:46 ` Steven Rostedt [this message]
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=1274816768.22648.220.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=chase.douglas@canonical.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    /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®