Re: [2.6 patch] kernel/sched*: optimize inlining

[Sam Ravnborg]

On Sun, May 11, 2008 at 09:49:52PM +0300, Adrian Bunk wrote:
> On Sun, May 11, 2008 at 07:52:22PM +0200, Sam Ravnborg wrote:
> > On Sun, May 11, 2008 at 12:21:32PM +0300, Adrian Bunk wrote:
> > > kernel/sched* contained tons of inline's, and the result of removing 
> > > them all is impressing (with x86_64_defconfig)
> > >    text    data     bss     dec     hex filename
> > >   39557    8234     280   48071    bbc7 kernel/sched.o
> > >   41792    8234     280   50306    c482 kernel/sched.o.old
> > > 
> > > That's a 5.3% text size reduction (!), which is more than twice as much 
> > > as the 2.3% the "optimized inlining" achieves on average for the whole 
> > > kernel.
> > 
> > If we compare the size of sched.o in the three cases we see a clear effect:
> > 
> >                   text	   data	    bss	    dec	    hex	filename
> > forced inline:    31257	   2702	    200	  34159	   856f	kernel/sched.o
> > inline hint:      31105	   2702	    200	  34007	   84d7	kernel/sched.o
> > no inline (hint): 30704	   2702	    200	  33606	   8346	kernel/sched.o
> 
> Is this with CONFIG_CC_OPTIMIZE_FOR_SIZE=y?
Yes.
And gcc is:
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)
on a i386 box (and built for i386).

> > The last line "no inline(hint)" is with Adrians patch applied.
> > So what is obvious from the above is that with the arch/gcc combination
> > I use here the inline hint has a clear effect and gcc inlines more
> > when we have given it a hint to do so than without the hint.
> > I conclude this solely on the cide size change between the line
> > "inline hint" and "no inline(hint)".
> > 
> > With adrians patch there were no difference in size with or
> > without the OPTIMIZE_INLINING enabled.
> > 
> > Or in other words the config option "OPTIMIZE_INLINING" is NOT
> > equal to removing all the inline annotations.
> 
> Both do the same with the same justification:
> 
> Both give the decision whether or not to inline completely into the 
> hands of gcc, which can make different inlining decisions depending on 
> e.g. the gcc version and the CONFIG_CC_OPTIMIZE_FOR_SIZE setting, and
> the only thing benchmarked is the code size.

You continue to fail to acknowledge that it is valueable information
that we pass gcc a _hint_ that it is a good idea to inline certain
functions.

The inline hint is there to tell gcc that it shall inline this function
in cases where it usual think it should not do so. Which invietably
will result in a larger codesize in some cases.

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