linux-kernel - Re: [PATCH 2/8] tracing: create automated trace defines

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: <alpine.DEB.2.00.0904220215530.9714@gandalf.stny.rr.com>
Date:	Wed, 22 Apr 2009 02:24:17 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@....de>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Zhaolei <zhaolei@...fujitsu.com>, Li Zefan <lizf@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	"Frank Ch. Eigler" <fche@...stic.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Michael Rubin <mrubin@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Neil Horman <nhorman@...driver.com>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	Pekka@...stfloor.org
Subject: Re: [PATCH 2/8] tracing: create automated trace defines

On Wed, 22 Apr 2009, Andi Kleen wrote:

> > I think it was Ingo that let out the idea, and I'm starting to like it.
> > 
> > Perhaps we should fork off gcc and ship Linux with its own compiler. This 
> > way we can optimize it for the kernel and not worry about any userland 
> > optimizations.
> > 
> > I would like to do something like:
> > 
> > 	if (unlikely(err)) {
> > 		__section__(".error_sect") {
> 
> 
> gcc already supports that, you don't need to fork anything. It's called
> hot/cold partitioning. Basically it splits functions into hot and cold
> and unlikely parts and all the cold/unlikely parts go into a separate 
> sections.
> 
> I think it's normally not enabled by default on x86 though, probably because
> it doesn't help too much.
> 
> By default (unless you specify -fno-reorder-blocks) it does the same
> without sections, just moving unlikely code out of line.

The unlikely code does not always get moved out that far. It still sits 
inside a function, and looking at the tracepoint code it did not move it 
far enough.

If you have a bunch of functions that each with an unlikely statement, 
those unlikely sections will still be interleaved within the function 
code.

In the case of tracepoints, it would be nice to move all the code that 
sets up the function call out of the hot paths. If we could move it to its 
own section, that would be much better.

Having all "unlikely"s go into a separate section would not help much, 
since according to the branch profiler there are a lot of "unlikely"s in 
the kernel that are not too unlikely.

If gcc can indeed move "unlikely" code completely out of the fast path, 
and put it into its own sections, then I think we should go through the 
kernel and start removing all "likely" and "unlikely"s that are not 99% 
accurate. Then we can enable the separate section cold paths and perhaps 
see a performance benefit.

-- Steve

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