From: Andi Kleen <ak@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: 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>
Subject: Re: [GIT] kbuild/lto changes for 3.15-rc1
Date: Wed, 9 Apr 2014 08:40:11 -0700 [thread overview]
Message-ID: <20140409154011.GB32556@tassilo.jf.intel.com> (raw)
In-Reply-To: <20140409060133.GA6766@gmail.com>
> 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.
See Honza's email. There are lots of benefits in various
large projects.
Also BTW compiler technology is not static. It's often
hard to interpolate from older releases, and to see
project benefits for different projects.
> 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),
I see about 40-60% build time penalty with gcc 4.9 / single link.
> which made LTO essentially a non-starter for development
> work. (And that was with the Gold linker.)
I see LTO as a "release build", as opposed to a development build.
I don't think it's a big problem in such a model. If you don't
like that model, just don't enable it.
> 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.
The concrete tangible advantages at this point are code size
on smaller configs. There are a variety of users who use it for that.
I think it's worth merging for that alone.
-Andi
next prev parent reply other threads:[~2014-04-09 15:43 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
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 [this message]
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=20140409154011.GB32556@tassilo.jf.intel.com \
--to=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=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