[Ksummit-discuss] Unconference session on getting LTO into the kernel?

[Ksummit-discuss] Unconference session on getting LTO into the kernel?

[Josh Triplett]

There's been a lot of discussion about link-time optimization of the
Linux kernel.  However, as of yet the patches have not yet gone in.
I've seen objections on the grounds that it increases build time and
memory usage, but those objections don't seem like reasons to omit the
patches, just reasons to keep LTO optional and disabled by default (and
potentially to prevent "allyesconfig" from enabling it).

Anyone interested in a session to hammer out the last details to get the
patches merged?

(If this mail ends up prompting discussion that settles this via email,
that'd be a fine result too.)

- Josh Triplett

Re: [Ksummit-discuss] Unconference session on getting LTO into the kernel?

[H. Peter Anvin]

On 08/16/2014 05:20 PM, Josh Triplett wrote:
> There's been a lot of discussion about link-time optimization of the
> Linux kernel.  However, as of yet the patches have not yet gone in.
> I've seen objections on the grounds that it increases build time and
> memory usage, but those objections don't seem like reasons to omit the
> patches, just reasons to keep LTO optional and disabled by default (and
> potentially to prevent "allyesconfig" from enabling it).
> 
> Anyone interested in a session to hammer out the last details to get the
> patches merged?
> 
> (If this mail ends up prompting discussion that settles this via email,
> that'd be a fine result too.)
> 

Last I heard you still needed a modified toolchain for kernel LTO to
work.  That is the real killer issue in my mind... if the toolchain
isn't available to people it is really hard to expect people to not
cause the code to bitrot.

	-hpa

Re: [Ksummit-discuss] Unconference session on getting LTO into the kernel?

[Josh Triplett]

On Sun, Aug 17, 2014 at 03:04:49PM -0700, H. Peter Anvin wrote:
> On 08/16/2014 05:20 PM, Josh Triplett wrote:
> > There's been a lot of discussion about link-time optimization of the
> > Linux kernel.  However, as of yet the patches have not yet gone in.
> > I've seen objections on the grounds that it increases build time and
> > memory usage, but those objections don't seem like reasons to omit the
> > patches, just reasons to keep LTO optional and disabled by default (and
> > potentially to prevent "allyesconfig" from enabling it).
> > 
> > Anyone interested in a session to hammer out the last details to get the
> > patches merged?
> > 
> > (If this mail ends up prompting discussion that settles this via email,
> > that'd be a fine result too.)
> > 
> 
> Last I heard you still needed a modified toolchain for kernel LTO to
> work.  That is the real killer issue in my mind... if the toolchain
> isn't available to people it is really hard to expect people to not
> cause the code to bitrot.

Looking at the last thread on it, it appears to require gcc 4.8 and
"Linux binutils" 2.21.51.0.3.  I assume the former isn't a problem, and
the latter appears to have been released in 2010.  What's the status of
either getting the necessary changes into GNU binutils or getting the
kernel LTO build to work with GNU binutils?

The comments in Makefile.lto say:
# We need HJ Lu's Linux binutils because mainline binutils does not
# support mixing assembler and LTO code in the same ld -r object.
Which seems like it would only affect a build with CONFIG_LTO_SLIM=n.
Could Makefile.lto allow GNU binutils with CONFIG_LTO_SLIM=y, and only
require the modified binutils with CONFIG_LTO_SLIM=n?

- Josh Triplett