From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Josh Triplett <josh@joshtriplett.org>,
Michal Marek <mmarek@suse.cz>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [GIT] kbuild/lto changes for 3.15-rc1
Date: Wed, 9 Apr 2014 10:17:09 +0200 [thread overview]
Message-ID: <20140409081709.GA283@x4> (raw)
In-Reply-To: <20140409060133.GA6766@gmail.com>
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
>
> * Andi Kleen <ak@linux.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@joshtriplett.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.
I did some measurements on Andi's lto-3.14 branch:
options size build time
------------------------------
-O2 4408880 1:56.98
-flto -O2 4213072 2:36.22
-Os 3833248 1:45.13
-flto -Os 3651504 2:34.51
This was measured on my AMD 4 core machine with a monolithic .config
where "CONFIG_MODULES is not set". The compiler is gcc trunk (4.9).
So on x86_86 you get 5% size reduction for 25-30% build time slowdown.
The huge RAM requirements of LTO are solved with gcc-4.9.
As for tooling support, the next version of binutils will support
automatic loading of the liblto_plugin and that will allow one to get
rid of the gcc wrappers (gcc-ar, etc.).
It is unfortunate that a special version of binutils is still required
to build the kernel, but that will change as soon as all "ld -r"
invocations are eliminated (I think Sam Ravnborg has a patch for this).
--
Markus
next prev parent reply other threads:[~2014-04-09 8:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-07 20:19 [GIT] kbuild/lto changes for 3.15-rc1 Michal Marek
2014-04-07 20:59 ` Andi Kleen
2014-04-08 15:26 ` Linus Torvalds
2014-04-08 20:49 ` josh
2014-04-08 22:44 ` Linus Torvalds
2014-04-09 1:35 ` Andi Kleen
2014-04-09 6:01 ` Ingo Molnar
2014-04-09 8:17 ` Markus Trippelsdorf [this message]
2014-04-14 10:32 ` Ingo Molnar
2014-04-14 10:46 ` Markus Trippelsdorf
2014-04-14 10:55 ` Ingo Molnar
2014-04-15 1:00 ` Josh Triplett
2014-04-15 1:52 ` Andi Kleen
2014-04-15 6:00 ` Ingo Molnar
2014-04-15 9:36 ` Ralf Baechle
2014-04-15 11:19 ` Sam Ravnborg
2014-04-15 11:36 ` Markus Trippelsdorf
2014-04-15 18:19 ` Sam Ravnborg
2014-04-15 18:29 ` Markus Trippelsdorf
2014-04-16 6:49 ` Ingo Molnar
2014-04-09 15:40 ` Andi Kleen
2014-04-08 22:49 ` Andi Kleen
2014-04-09 0:10 ` Jan Hubicka
2014-04-09 1:23 ` Andi Kleen
2014-04-09 0:14 ` Tim Bird
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140409081709.GA283@x4 \
--to=markus@trippelsdorf.de \
--cc=ak@linux.intel.com \
--cc=josh@joshtriplett.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mmarek@suse.cz \
--cc=sam@ravnborg.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).