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

Message-ID: <20140409060133.GA6766@gmail.com>
Date:	Wed, 9 Apr 2014 08:01:33 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Josh Triplett <josh@...htriplett.org>,
	Michal Marek <mmarek@...e.cz>,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT] kbuild/lto changes for 3.15-rc1


* Andi Kleen <ak@...ux.intel.com> wrote:

> On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > On Tue, Apr 8, 2014 at 1:49 PM,  <josh@...htriplett.org> wrote:
> > >
> > > In addition to making the kernel smaller and such (I'll leave the
> > > specific stats there to Andi), here's the key awesomeness of LTO that
> > > you, personally, should find useful and compelling: LTO will eliminate
> > > the need to add many lower-level Kconfig symbols to compile out bits of
> > > the kernel.
> > 
> > Actually that, to me, is a negative right now.
> > 
> > Since there's no way we'll make LTO the default in the foreseeable
> > future, people starting to use it like that is just a bad bad thing.
> > 
> > So really, the main advantage of LTO would be any actual 
> > optimizations it can do. And call me anal, but I want *numbers* 
> > for that before I merge it. Not handwaving. I'm not actually aware 
> > of how well - if at all - code generation actually improves.
> 
> Well it looks very different if you look at the generated code. gcc 
> becomes a lot more aggressive.
> 
> But as I said there's currently no significant performance 
> improvement known, so if your only goal is better performance this 
> patch (as currently) known is not a big winner.  My suspicion is 
> that's mostly because the standard benchmarks we run are not too 
> compiler sensitive.
> 
> However the users seem to care about the other benefits, like code 
> size.
> 
> And there may well be loads that are compiler sensitive. As Honza 
> posted, for non kernel workloads LTO is known to have large 
> benefits.
> 
> Besides at this point it's pretty much just some additions to the 
> Makefiles.

So the reason I've been mostly ignoring the LTO patches myself (I only 
took LTO related changes that had other justifications such as 
cleanups) is that I've actually implemented full LTO in a userspace 
project myself, and my experience was:

  1) There was very little if any measurable LTO runtime speedup, 
     despite agressive GCC options and despite user-space generally 
     offering more optimizations opportunities than kernel space.

  2) LTO with current build tools meant a 1.5x-3x build speed
     slowdown (on a very fast box with tons of CPUs and RAM),
     which made LTO essentially a non-starter for development
     work. (And that was with the Gold linker.)

and looking at your characterisation of LTO you only conceded
#1 much after you started pushing LTO and you are clearly trying
to avoid talking about #2 while it's very much relevant...

I'm willing to be convinced by actual numbers, and LTO tooling might 
eventually improve, etc., but right now LTO is much ado about very 
little, being pushed in a somewhat dishonest way.

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/