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

Steven Rostedt
2009-04-22T06:24:32Z

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