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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 May 2008 19:52:22 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [2.6 patch] kernel/sched*: optimize inlining

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

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.

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

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/