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

[Steven Rostedt]

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