On Tue, Dec 8, 2020 at 2:20 PM Arnd Bergmann <a...@kernel.org> wrote: > > On Tue, Dec 8, 2020 at 10:10 PM 'Nick Desaulniers' via Clang Built > Linux <clang-built-li...@googlegroups.com> wrote: > > > > On Tue, Dec 8, 2020 at 1:00 PM Arnd Bergmann <a...@kernel.org> wrote: > > > > > > On Tue, Dec 8, 2020 at 5:43 PM 'Sami Tolvanen' via Clang Built Linux > > > <clang-built-li...@googlegroups.com> wrote: > > > > > > > > On Tue, Dec 8, 2020 at 4:15 AM Arnd Bergmann <a...@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.
Sure, that sounds reasonable to me. I'll add it in v9. Sami
