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]

Date:	Tue, 8 Apr 2014 18:35:57 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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

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.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/