[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1274815906.9757.83.camel@cndougla-ubuntu>
Date: Tue, 25 May 2010 15:31:46 -0400
From: Chase Douglas <chase.douglas@...onical.com>
To: Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>
Cc: linux-kernel@...r.kernel.org
Subject: Tracing configuration review
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists