lkml.org 
[lkml]   [2012]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: Link Time Optimization support for the kernel

    * Andi Kleen <andi@firstfloor.org> wrote:

    > On Mon, Aug 20, 2012 at 09:48:35AM +0200, Ingo Molnar wrote:
    > >
    > > * Andi Kleen <andi@firstfloor.org> wrote:
    > >
    > > > This rather large patchkit enables gcc Link Time Optimization (LTO)
    > > > support for the kernel.
    > > >
    > > > With LTO gcc will do whole program optimizations for
    > > > the whole kernel and each module. This increases compile time,
    > > > but can generate faster code.
    > >
    > > By how much does it increase compile time?
    >
    > All numbers are preliminary at this point. I miss both some
    > code quality and compile time improvements that it could do,
    > to work around some issues that are fixable.
    >
    > Compile time:
    >
    > Compilation slowdown depends on the largest binary size. I
    > see between 50% and 4x. The 4x case is mainly for allyes (so
    > unlikely); a normal distro build, which is mostly modular, or
    > a defconfig like build is more towards the 50%.
    >
    > Currently I have to disable slim LTO, which essentially means
    > everything is compiled twice. Once that's fixed it should
    > compile faster for the normal case too (although it will be
    > still slower than non LTO)

    The other hope would be that if LTO is used by a high-profile
    project like the Linux kernel then the compiler folks might look
    at it and improve it.

    > A lot of the overhead on the larger builds is also some
    > specific gcc code that I'm working with the gcc developers on
    > to improve. So the 4x extreme case will hopefully go down.
    >
    > The large builds also currently suffer from too much memory
    > consumption. That will hopefully improve too, as gcc improves.

    Are there any LTO build files left around, blowing up the size
    of the build tree?

    > I wouldn't expect anyone using it for day to day kernel hacking
    > (I understand that 50% are annoying for that). It's more like a
    > "release build" mode.
    >
    > The performance is currently also missing some improvements
    > due to workarounds.
    >
    > Performance:
    >
    > Hackbench goes about 5% faster, so the scheduler benefits.
    > Kbuild is not changing much. Various network benchmarks over
    > loopback go faster too (best case seen 18%+), so the network
    > stack seems to benefit. A lot of micro benchmarks go faster,
    > sometimes larger numbers. There are some minor regressions.
    >
    > A lot of benchmarking on larger workloads is still
    > outstanding. But the existing numbers are promising I believe.
    > Things will still change, it's still early.
    >
    > I would welcome any benchmarking from other people.
    >
    > I also expect gcc to do more LTO optimizations in the future,
    > so we'll hopefully see more gains over time. Essentially it
    > gives more power to the compiler.
    >
    > Long term it would also help the kernel source organization.
    > For example there's no reason with LTO to have gigantic
    > includes with large inlines, because cross file inlining works
    > in a efficient way without reparsing.

    Can the current implementation of LTO optimize to the level of
    inlining? A lot of our include file hell situation results from
    the desire to declare structures publicly so that inlined
    functions can use them directly.

    If data structures could be encapsulated/internalized to
    subsystems and only global functions are exposed to other
    subsystems [which are then LTO optimized] then our include
    file dependencies could become a *lot* simpler.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2012-08-21 10:21    [W:2.633 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site