lkml.org 
[lkml]   [2020]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v8 00/16] Add support for Clang LTO
    On Tue, Dec 8, 2020 at 10:10 PM 'Nick Desaulniers' via Clang Built
    Linux <clang-built-linux@googlegroups.com> wrote:
    >
    > On Tue, Dec 8, 2020 at 1:00 PM Arnd Bergmann <arnd@kernel.org> wrote:
    > >
    > > On Tue, Dec 8, 2020 at 5:43 PM 'Sami Tolvanen' via Clang Built Linux
    > > <clang-built-linux@googlegroups.com> wrote:
    > > >
    > > > On Tue, Dec 8, 2020 at 4:15 AM Arnd Bergmann <arnd@kernel.org> wrote:
    > > > >
    > > > > - one build seems to take even longer to link. It's currently at 35GB RAM
    > > > > usage and 40 minutes into the final link, but I'm worried it might
    > > > > not complete
    > > > > before it runs out of memory. I only have 128GB installed, and google-chrome
    > > > > uses another 30GB of that, and I'm also doing some other builds in parallel.
    > > > > Is there a minimum recommended amount of memory for doing LTO builds?
    > > >
    > > > When building arm64 defconfig, the maximum memory usage I measured
    > > > with ThinLTO was 3.5 GB, and with full LTO 20.3 GB. I haven't measured
    > > > larger configurations, but I believe LLD can easily consume 3-4x that
    > > > much with full LTO allyesconfig.
    > >
    > > Ok, that's not too bad then. Is there actually a reason to still
    > > support full-lto
    > > in your series? As I understand it, full LTO was the initial approach and
    > > used to work better, but thin LTO is actually what we want to use in the
    > > long run. Perhaps dropping the full LTO option from your series now
    > > that thin LTO works well enough and uses less resources would help
    > > avoid some of the problems.
    >
    > While all developers agree that ThinLTO is a much more palatable
    > experience than full LTO; our product teams prefer the excessive build
    > time and memory high water mark (at build time) costs in exchange for
    > slightly better performance than ThinLTO in <benchmarks that I've been
    > told are important>. Keeping support for full LTO in tree would help
    > our product teams reduce the amount of out of tree code they have. As
    > long as <benchmarks that I've been told are important> help
    > sell/differentiate phones, I suspect our product teams will continue
    > to ship full LTO in production.

    Ok, fair enough. How about marking FULL_LTO as 'depends on
    !COMPILE_TEST' then? I'll do that locally for my randconfig tests,
    but it would help the other build bots that also force-enable
    COMPILE_TEST.

    Arnd

    \
     
     \ /
      Last update: 2020-12-08 23:22    [W:5.265 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site