linux-kernel - Re: Tracing configuration review

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100525201259.GA5370@nowhere>
Date:	Tue, 25 May 2010 22:13:08 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Chase Douglas <chase.douglas@...onical.com>,
	Prasad <prasad@...ux.vnet.ibm.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	Soeren Sandmann <sandmann@...mi.au.dk>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: Tracing configuration review

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/