Messages in this thread | | | Date | Wed, 22 Apr 2009 02:24:17 -0400 (EDT) | From | Steven Rostedt <> | 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
| |