Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Dec 2020 13:09:54 -0800
From: Nick Desaulniers <>
To: Arnd Bergmann <>
Cc: Sami Tolvanen <>, Masahiro Yamada <>, 
	Steven Rostedt <>, Will Deacon <>, 
	Josh Poimboeuf <>, Peter Zijlstra <>, 
	Greg Kroah-Hartman <>, "Paul E. McKenney" <>, 
	Kees Cook <>, 
	clang-built-linux <>, 
	Kernel Hardening <>, 
	linux-arch <>, 
	Linux ARM <>, 
	Linux Kbuild mailing list <>, 
	"" <>, linux-pci <>
Subject: Re: [PATCH v8 00/16] Add support for Clang LTO

On Tue, Dec 8, 2020 at 1:00 PM Arnd Bergmann <> wrote:
> On Tue, Dec 8, 2020 at 5:43 PM 'Sami Tolvanen' via Clang Built Linux
> <> wrote:
> >
> > On Tue, Dec 8, 2020 at 4:15 AM Arnd Bergmann <> 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.
~Nick Desaulniers

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.