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

[Steven Rostedt]

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


--
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/