linux-kernel - Re: [GIT] kbuild/lto changes for 3.15-rc1

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] [day] [month] [year] [list]

Date:	Wed, 16 Apr 2014 08:49:07 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Josh Triplett <josh@...htriplett.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michal Marek <mmarek@...e.cz>,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	John Crispin <blogic@...nwrt.org>
Subject: Re: [GIT] kbuild/lto changes for 3.15-rc1


* Markus Trippelsdorf <markus@...ppelsdorf.de> wrote:

> On 2014.04.15 at 20:19 +0200, Sam Ravnborg wrote:
> > On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
> > > On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
> > > > > 
> > > > > And while the code size reduction is less for MIPS than what others have
> > > > > reported for their platforms (I'm still investigating) is still is enough
> > > > > that embedded developers would commit murder for.
> > > > 
> > > > I have experimented a little with a patch that links all of vmlinux in one step.
> > > > I compared the text size of vmlinux without and with -ffunction-sections.
> > > > 
> > > > With a defconfig build on x86 (32 bit) I got following results:
> > > > 
> > > >                         size     difference
> > > > singlelink          10266506
> > > > function-sections    9487369         779137  7,5%
> > > > 
> > > > So this is a reduction of ~800 kb by enabling -ffunction-sections which
> > > > allows the linker to throw away unused sections.
> > > > 
> > > > I have not boot tested the kernel so chances are that too much was thrown out by the linker.
> > > > But this is an option that has much smaller cost to use than lto.
> > > > And seems to benefit nicely in size.
> > > > 
> > > > I have not tried this wihtout my singlelink patch - but I assume similar results.
> > > 
> > > No, it wouldn't work, because you cannot mix -r and --gc-sections (or
> > > gold's --icf (identical code folding)).
> 
> BTW using --gc-sections during vmlinux link time will not work, because
> it will "garbage collect" the whole kernel away.
> 
> > With make allnoconfig I see a 5% decrease in text size by applying -ffunction-sections.
> > This is with latest mainline and no other than the following applied:
> > 
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 602f57e..51bac0a 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -171,6 +171,8 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> >  KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
> >  KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
> >  
> > +KBUILD_CFLAGS += -ffunction-sections
> > +
> >  KBUILD_CFLAGS += $(mflags-y)
> >  KBUILD_AFLAGS += $(mflags-y)
> >  
> > 
> > What can then explain this size difference?

I haven't looked at this for some time, but won't the linker eliminate 
unused input sections by default, unless told not to do that? (You 
have to add --no-gc-sections explicitly to turn this off.)

That would mean that with per function sections, unused global 
functions are eliminated. 'Unused' here means that the section only 
contains symbols that are not referenced anywhere else. With 
-ffunction-sections we'll have a lot of small per function sections, 
with a single symbol in them (the function) most of the time, IIRC.

> That is a good question. Because one would expect that adding 
> -ffunction-sections should increase the size (and it does with my 
> config).

--gc-sections appears to be platform dependent, so I suspect it 
depends on the platform.

But if -ffunction-sections can be made to work and has fewer downsides 
than the upsides then that approach should be tried first, and then 
LTO should be compared to that baseline.

Thanks,

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