Messages in this thread | | | Subject | Tracing configuration review | From | Chase Douglas <> | Date | Tue, 25 May 2010 15:31:46 -0400 |
| |
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
| |