From: Nick Desaulniers <ndesaulniers@google.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>,
Masahiro Yamada <masahiroy@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Will Deacon <will@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Kees Cook <keescook@chromium.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
linux-arch <linux-arch@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v8 00/16] Add support for Clang LTO
Date: Tue, 8 Dec 2020 13:09:54 -0800 [thread overview]
Message-ID: <CAKwvOd=hL=Vt1ATYqky9jmv+tM5hpTnLRuZudG-7ki0EYoFGJQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a1Xfpt7QLkvxjtXKcgzcWkS8g9bmxD687+rqjTafTzKrg@mail.gmail.com>
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.
--
Thanks,
~Nick Desaulniers
next prev parent reply other threads:[~2020-12-08 21:11 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 21:36 [PATCH v8 00/16] Add support for Clang LTO Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 01/16] tracing: move function tracer options to Kconfig Sami Tolvanen
2020-12-01 21:47 ` Steven Rostedt
2020-12-01 21:36 ` [PATCH v8 02/16] kbuild: add support for Clang LTO Sami Tolvanen
2020-12-02 2:59 ` Masahiro Yamada
2020-12-03 0:07 ` Nick Desaulniers
2020-12-01 21:36 ` [PATCH v8 03/16] kbuild: lto: fix module versioning Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 04/16] kbuild: lto: limit inlining Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 05/16] kbuild: lto: merge module sections Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 06/16] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 07/16] init: lto: ensure initcall ordering Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 08/16] init: lto: fix PREL32 relocations Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 09/16] PCI: Fix PREL32 relocations for LTO Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 10/16] modpost: lto: strip .lto from module names Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 11/16] scripts/mod: disable LTO for empty.c Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 12/16] efi/libstub: disable LTO Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 13/16] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 14/16] arm64: vdso: disable LTO Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 15/16] arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGS Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 16/16] arm64: allow LTO to be selected Sami Tolvanen
2020-12-03 0:01 ` [PATCH v8 00/16] Add support for Clang LTO Nick Desaulniers
2020-12-03 11:26 ` Will Deacon
2020-12-03 17:07 ` Sami Tolvanen
2020-12-03 18:21 ` Nathan Chancellor
2020-12-03 18:22 ` Will Deacon
2020-12-03 22:32 ` Nick Desaulniers
2020-12-04 9:35 ` Will Deacon
2020-12-04 22:52 ` Sami Tolvanen
2020-12-06 6:50 ` Nathan Chancellor
2020-12-06 20:09 ` Sami Tolvanen
2020-12-08 0:46 ` Nathan Chancellor
2020-12-08 12:15 ` Arnd Bergmann
2020-12-08 13:54 ` Arnd Bergmann
2020-12-08 16:53 ` Sami Tolvanen
2020-12-08 16:56 ` Arnd Bergmann
2020-12-08 16:43 ` Sami Tolvanen
[not found] ` <CAK8P3a1Xfpt7QLkvxjtXKcgzcWkS8g9bmxD687+rqjTafTzKrg@mail.gmail.com>
2020-12-08 21:09 ` Nick Desaulniers [this message]
2020-12-08 22:20 ` Arnd Bergmann
2020-12-09 16:11 ` Sami Tolvanen
[not found] ` <CAK8P3a3O65m6Us=YvCP3QA+0kqAeEqfi-DLOJa+JYmBqs8-JcA@mail.gmail.com>
2020-12-09 5:23 ` Fāng-ruì Sòng
2020-12-09 9:07 ` Arnd Bergmann
2020-12-09 16:09 ` Sami Tolvanen
2020-12-09 19:24 ` Arnd Bergmann
2020-12-09 4:55 ` Fangrui Song
2020-12-09 9:19 ` Arnd Bergmann
2020-12-09 12:35 ` Arnd Bergmann
2020-12-09 16:25 ` Sami Tolvanen
2020-12-09 17:51 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKwvOd=hL=Vt1ATYqky9jmv+tM5hpTnLRuZudG-7ki0EYoFGJQ@mail.gmail.com' \
--to=ndesaulniers@google.com \
--cc=arnd@kernel.org \
--cc=clang-built-linux@googlegroups.com \
--cc=gregkh@linuxfoundation.org \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).