Prev: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
Next: sata_nv times out for BD-ROM iHOS104-08
From: Chase Douglas on 25 May 2010 15:40
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 25 May 2010 15:50
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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Chase Douglas on 25 May 2010 16:00
On Tue, 2010-05-25 at 15:46 -0400, Steven Rostedt wrote:
> 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)

(I would have snipped much of the above, but since I've added CC for the
Ubuntu list I wanted to leave it as is for this first reply)

After enabling KSYM_TRACER, I was presented with PROFILE_KSYM_TRACER.
This is also "Say N if unsure," so I could use some guidance on whether
we should turn it on as well.

Thanks,

-- Chase

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 25 May 2010 16:20
On Tue, May 25, 2010 at 03:31:46PM -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.



Ok.



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


Indeed.



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


It is the upstream kernel implementation for sysprof:
http://www.daimi.au.dk/~sandmann/sysprof/

But I suspect it is not used widely. I think the users
prefer the out of tree module.

And IIRC, sysprof now can use the perf interface instead. I
guess we can think about it as deprecated.

Soeren could tell more about it.


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


We want to deprecate it in the long term, but for now we
don't have any replacement. Cool for RT latency tracing.



> CONFIG_FTRACE_SYSCALLS=y (no performance impact by default)



Yeah, this one is fine, and nice to have.



> CONFIG_BOOT_TRACER=y (no performance impact by default)


Yep.
It is targeted for deprecation in the long term but we don't have
the replacement yet.



> CONFIG_KSYM_TRACER=y (no performance impact by default)


IMO, it is deprecated. The perf interface is much more powerful and flexible.
Prasad, do you agree if I remove this ftrace plugin?



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



Can be useful to track places that eats most the stack.
No overhead if off and CONFIG_DYNAMIC_FTRACE.

Again, it is targeted for deprecation in the long term but
we don't have any replacement yet.



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



Deprecated. We have the kmem trace event that are a full replacement now.
Pekka, Gabriel, can we remove it now?



> CONFIG_WORKQUEUE_TRACER=y (no performance impact by default)


In the way for deprecation.



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



So, if you have HAVE_DYNAMIC_FTRACE=n, you want to avoid any of
the following:

CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_FUNCTION_PROFILER=y

Because these will have a noticeable overhead even when they are disabled.
Otherwise if you have CONFIG_DYNAMIC_FTRACE=y, the four above are safe
wrt performance when they are =y but disabled.

And they are nice features. We want to make them use the trace events
interface, which means we'll probably deprecate them in the long term,
but that will be only to change their interface (like most of the
other tracing features targeted for deprecation).

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 25 May 2010 16:20
On Tue, May 25, 2010 at 03:46:08PM -0400, Steven Rostedt wrote:
> On Tue, 2010-05-25 at 15:31 -0400, Chase Douglas wrote:
> > # 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.



Doesn't actually CONTEXT_SWITCH_TRACER has the code for the
comm things?


> > CONFIG_BOOT_TRACER=y (no performance impact by default)
>
> But this tracer is pretty useless. It gives no more information than
> debug_initcalls.



Yeah it's pretty useless. And these informations can also be displayed
through printk on boot so...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
Next: sata_nv times out for BD-ROM iHOS104-08