Re: [PATCH 08/10] jump label v11: x86 support

[Jason Baron <jbaron@redhat.com>]

On Tue, Sep 21, 2010 at 11:35:24AM -0400, Steven Rostedt wrote:
> 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.
> 

No, OPTIMIZE_FOR_SIZE doesn't break anything, its just that the
'dormant' or the cold code path, isn't moved out of line.

I believe the current approach will eventually lead us to an optimal solution,
(single no-op in the fast path, with ability to jump patch to
out-of-line cold code), even if its not quite there yet under this
compiler flag. And the inclusion of this code will provide more of an
impetus for gcc to make further optimizations.

thanks,

-Jason