lkml.org 
[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Tracing configuration review
From
Date
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




\
 
 \ /
  Last update: 2010-05-25 21:49    [W:0.189 / U:7.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site