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

From: Adrian Bunk
Date: Sun May 11 2008 - 14:51:24 EST


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?

Otherwise your data has not much value since that's the interesting case
for size comparisons and AFAIK also the common case in distribution
kernels.

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

And if gcc produces with CONFIG_CC_OPTIMIZE_FOR_SIZE=y bigger code due
to some hint I'd argue that's a bug in gcc that might get fixed in
future gcc releases.

> > Note that any remarks regarding whether this patch might affect the
> > performance are invalid since noone cared about the performance when
> > the "x86: add optimized inlining" commit that does the same for the
> > whole kernel entered the tree.
>
> In one case it was an option it was easy to turn off/on so we could
> compare and modulus bugs it was a noop on gcc < 4.0.
> With the patch below we revet back to the broken gcc inline algorithm on
> gcc < 4.0 and it cannot as easy be turned of (have to revert this patch).
> Both issues are worth to consider before applying this.

Do we have any hard data that gcc < 4.0 has a "broken inline algorithm"
and gcc >= 4.0 has a "working inline algorithm"?

> Sam

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

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