Messages in this thread | | | Date | Sun, 11 May 2008 21:49:52 +0300 | From | Adrian Bunk <> | Subject | Re: [2.6 patch] kernel/sched*: optimize inlining |
| |
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
| |