Messages in this thread | | | Subject | Re: [PATCH 08/10] jump label v11: x86 support | From | Steven Rostedt <> | Date | Tue, 21 Sep 2010 11:35:24 -0400 |
| |
On Tue, 2010-09-21 at 17:29 +0200, Ingo Molnar wrote:
> > >From the documentation patch: > > > > " The optimization depends on !CC_OPTIMIZE_FOR_SIZE. When > > CC_OPTIMIZE_FOR_SIZE is set, gcc does not always out of line the not > > taken label path in the same way that the "if unlikely()" paths are > > made out of line. Thus, with CC_OPTIMIZE_FOR_SIZE set, this > > optimization is not always optimal. This may be solved in subsequent > > gcc versions, that allow us to move labels out of line, while still > > optimizing for size. " > > OTOH making a difficult optimization (HAVE_ARCH_JUMP_LABEL) dependent on > compiler flags is really asking for trouble. > > So how about enabling it unconditionally, and just chalk up the cost > under CC_OPTIMIZE_FOR_SIZE as one of the costs it already has? This also > has the advantage that future compilers can improve things without > having to wait for yet another kernel patch that re-enables > HAVE_ARCH_JUMP_LABEL.
Agreed,
CC_OPTIMIZE_FOR_SIZE does not mean OPTIMIZE_FOR_PERFORMANCE. Although people have argued that with smaller size you gain better cache performance. I've noticed that the general case is that optimizing for size has decreased performance (although I have not done any official benchmarks, just my own personal observations).
I thought you may have had that there because OPTIMIZE_FOR_SIZE actually broke the code (as some gcc compilers do for function graph tracer). If its just a "we don't perform better with this set". Then get rid of it.
Thanks,
-- Steve
| |