public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Marek <mmarek@suse.cz>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	hubicka@ucw.cz, jmario@redhat.com
Subject: Re: [GIT] kbuild/lto changes for 3.15-rc1
Date: Tue, 8 Apr 2014 15:49:26 -0700	[thread overview]
Message-ID: <20140408224926.GY32556@tassilo.jf.intel.com> (raw)
In-Reply-To: <CA+55aFy8hWqBpF1TXOPvA2rRaZp=H2LTO3wd3AERspmcGZhAeQ@mail.gmail.com>

Hi Linus,

> So right now, I see several reasons not to merge it ("It's so
> experimental that we don't even want to encourage people to test it"

I don't want them to enable it during allyesconfig because they
might need more than 4GB of RAM to build it (especially with gcc 
4.8, 4.9 is better). But allyesconfig is a special case. More standard
kernels with smaller vmlinux don't have this problem, but build
somewhat slower.

> to "it's not fully fleshed out yet and makes compile times _much_
> longer").

It's functionally stable, I have a number of users who
don't report any problems.

> 
> And yet nobody has actually talked about why I *should* merge it.
> 
> Which - I think understandably - makes me less than enthusiastic.
> 
> So I think I'll let this wait a bit longer, _unless_ people start
> talking about the upsides. How much smaller is the end result? How
> much faster is it? How much more beautiful is it? Does it make new

The smaller part is mainly visible with small kernels, because
it's very good at throwing out unused code there.  All the
stuff in kernel etc. that is not used.

For example Tim Bird saw ~11% binary reduction on ARM with his 
configs [1]. We also see some reduction in small configs.

Some of the static measures like nice, for example
a LTO kernel has ~4% less calls.

We did some performance tests, but at least in the standard
macro benchmarks we do there wasn't a clear performance
win.  LKP had a small win, but nothing dramatic.
But I would like others to test it on their workloads.

In principle LTO can do cool optimizations, like propagating
constants into functions (e.g. generate specialized versions
of some code). I experimented a bit with this, however
it currently seems to bloat the code quite a bit.

There are some other possible future optimizations
that can be enabled by a global optimizer.

Honza may have more reasons for LTO.

Other benefits are global warnings and some additional
type checking. The LTO log files are really useful
to do global call graph analysis and similar.

-Andi

[1] http://elinux.org/images/9/9e/Bird-Kernel-Size-Optimization-LCJ-2013.pdf

-- 
ak@linux.intel.com -- Speaking for myself only

  parent reply	other threads:[~2014-04-08 22:50 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
2014-04-08 22:49   ` Andi Kleen [this message]
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=20140408224926.GY32556@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=hubicka@ucw.cz \
    --cc=jmario@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.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