From: Arnd Bergmann <arnd@kernel.org> To: Sedat Dilek <sedat.dilek@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>, Mark Brown <broonie@kernel.org>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Kristina Martsenko <kristina.martsenko@arm.com>, Ionela Voinescu <ionela.voinescu@arm.com>, Mark Rutland <mark.rutland@arm.com>, Andrew Scull <ascull@google.com>, David Brazdil <dbrazdil@google.com>, Marc Zyngier <maz@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Clang-Built-Linux ML <clang-built-linux@googlegroups.com> Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Date: Fri, 26 Feb 2021 09:14:09 +0100 [thread overview] Message-ID: <CAK8P3a1QmS6g3cHTR93wWPkKs8vaP6RJEb8nZbTMLX+xphLJRw@mail.gmail.com> (raw) In-Reply-To: <CA+icZUUDnKBxkfgOVYDdpA29GnLUTT22mqRNyxQeYmay044ejg@mail.gmail.com> On Fri, Feb 26, 2021 at 1:36 AM Sedat Dilek <sedat.dilek@gmail.com> wrote: > > On Thu, Feb 25, 2021 at 12:21 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > From: Arnd Bergmann <arnd@arndb.de> > > > > When looking at kernel size optimizations, I found that arm64 > > does not currently support HAVE_LD_DEAD_CODE_DATA_ELIMINATION, > > which enables the --gc-sections flag to the linker. > > > > I see that for a defconfig build with llvm, there are some > > notable improvements from enabling this, in particular when > > combined with the recently added CONFIG_LTO_CLANG_THIN > > and CONFIG_TRIM_UNUSED_KSYMS: > > > > text data bss dec hex filename > > 16570322 10998617 506468 28075407 1ac658f defconfig/vmlinux > > 16318793 10569913 506468 27395174 1a20466 trim_defconfig/vmlinux > > 16281234 10984848 504291 27770373 1a7be05 gc_defconfig/vmlinux > > 16029705 10556880 504355 27090940 19d5ffc gc+trim_defconfig/vmlinux > > 17040142 11102945 504196 28647283 1b51f73 thinlto_defconfig/vmlinux > > 16788613 10663201 504196 27956010 1aa932a thinlto+trim_defconfig/vmlinux > > 16347062 11043384 502499 27892945 1a99cd1 gc+thinlto_defconfig/vmlinux > > 15759453 10532792 502395 26794640 198da90 gc+thinlto+trim_defconfig/vmlinux > > > > Thanks for the numbers. > Does CONFIG_TRIM_UNUSED_KSYMS=y have an impact to the build-time (and > disc-usage - negative way means longer/bigger)? > Do you have any build-time for the above numbers? They are in the mailing list archive I linked to: ==== defconfig ==== 332.001786355 seconds time elapsed 8599.464163000 seconds user 676.919635000 seconds sys ==== trim_defconfig ==== 448.378576012 seconds time elapsed 10735.489271000 seconds user 964.006504000 seconds sys ==== gc_defconfig ==== 324.347492236 seconds time elapsed 8465.785800000 seconds user 614.899797000 seconds sys ==== gc+trim_defconfig ==== 429.188875620 seconds time elapsed 10203.759658000 seconds user 871.307973000 seconds sys ==== thinlto_defconfig ==== 389.793540200 seconds time elapsed 9491.665320000 seconds user 664.858109000 seconds sys ==== thinlto+trim_defconfig ==== 580.431820561 seconds time elapsed 11429.515538000 seconds user 1056.985745000 seconds sys ==== gc+thinlto_defconfig ==== 389.484364525 seconds time elapsed 9473.831980000 seconds user 675.057675000 seconds sys ==== gc+thinlto+trim_defconfig ==== 580.824912807 seconds time elapsed 11433.650337000 seconds user 1049.845569000 seconds sys So HAVE_LD_DEAD_CODE_DATA_ELIMINATION is a small improvement on build time (since it can spend less time linking), while CONFIG_TRIM_UNUSED_KSYMS slows it down quite a bit. Combining CONFIG_TRIM_UNUSED_KSYMS with CONFIG_THINLTO is really slow because here most of the time is spent in the final link (especially when you have many CPU cores to do the earlier bits quickly), but then it does the link twice. > BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)? > ( Did not look or check for it. ) No, in mainline, HAVE_LD_DEAD_CODE_DATA_ELIMINATION is currently only selected on MIPS and PowerPC. I only sent experimental patches to enable it on arm64 and m68k, but have not tried booting them. If you select the symbol on x86, you should see similar results. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org> To: Sedat Dilek <sedat.dilek@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com>, Ionela Voinescu <ionela.voinescu@arm.com>, Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>, Catalin Marinas <catalin.marinas@arm.com>, Nick Desaulniers <ndesaulniers@google.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Kristina Martsenko <kristina.martsenko@arm.com>, Ard Biesheuvel <ardb@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Clang-Built-Linux ML <clang-built-linux@googlegroups.com>, Mark Brown <broonie@kernel.org>, Andrew Scull <ascull@google.com>, Marc Zyngier <maz@kernel.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Will Deacon <will@kernel.org>, David Brazdil <dbrazdil@google.com>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Date: Fri, 26 Feb 2021 09:14:09 +0100 [thread overview] Message-ID: <CAK8P3a1QmS6g3cHTR93wWPkKs8vaP6RJEb8nZbTMLX+xphLJRw@mail.gmail.com> (raw) In-Reply-To: <CA+icZUUDnKBxkfgOVYDdpA29GnLUTT22mqRNyxQeYmay044ejg@mail.gmail.com> On Fri, Feb 26, 2021 at 1:36 AM Sedat Dilek <sedat.dilek@gmail.com> wrote: > > On Thu, Feb 25, 2021 at 12:21 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > From: Arnd Bergmann <arnd@arndb.de> > > > > When looking at kernel size optimizations, I found that arm64 > > does not currently support HAVE_LD_DEAD_CODE_DATA_ELIMINATION, > > which enables the --gc-sections flag to the linker. > > > > I see that for a defconfig build with llvm, there are some > > notable improvements from enabling this, in particular when > > combined with the recently added CONFIG_LTO_CLANG_THIN > > and CONFIG_TRIM_UNUSED_KSYMS: > > > > text data bss dec hex filename > > 16570322 10998617 506468 28075407 1ac658f defconfig/vmlinux > > 16318793 10569913 506468 27395174 1a20466 trim_defconfig/vmlinux > > 16281234 10984848 504291 27770373 1a7be05 gc_defconfig/vmlinux > > 16029705 10556880 504355 27090940 19d5ffc gc+trim_defconfig/vmlinux > > 17040142 11102945 504196 28647283 1b51f73 thinlto_defconfig/vmlinux > > 16788613 10663201 504196 27956010 1aa932a thinlto+trim_defconfig/vmlinux > > 16347062 11043384 502499 27892945 1a99cd1 gc+thinlto_defconfig/vmlinux > > 15759453 10532792 502395 26794640 198da90 gc+thinlto+trim_defconfig/vmlinux > > > > Thanks for the numbers. > Does CONFIG_TRIM_UNUSED_KSYMS=y have an impact to the build-time (and > disc-usage - negative way means longer/bigger)? > Do you have any build-time for the above numbers? They are in the mailing list archive I linked to: ==== defconfig ==== 332.001786355 seconds time elapsed 8599.464163000 seconds user 676.919635000 seconds sys ==== trim_defconfig ==== 448.378576012 seconds time elapsed 10735.489271000 seconds user 964.006504000 seconds sys ==== gc_defconfig ==== 324.347492236 seconds time elapsed 8465.785800000 seconds user 614.899797000 seconds sys ==== gc+trim_defconfig ==== 429.188875620 seconds time elapsed 10203.759658000 seconds user 871.307973000 seconds sys ==== thinlto_defconfig ==== 389.793540200 seconds time elapsed 9491.665320000 seconds user 664.858109000 seconds sys ==== thinlto+trim_defconfig ==== 580.431820561 seconds time elapsed 11429.515538000 seconds user 1056.985745000 seconds sys ==== gc+thinlto_defconfig ==== 389.484364525 seconds time elapsed 9473.831980000 seconds user 675.057675000 seconds sys ==== gc+thinlto+trim_defconfig ==== 580.824912807 seconds time elapsed 11433.650337000 seconds user 1049.845569000 seconds sys So HAVE_LD_DEAD_CODE_DATA_ELIMINATION is a small improvement on build time (since it can spend less time linking), while CONFIG_TRIM_UNUSED_KSYMS slows it down quite a bit. Combining CONFIG_TRIM_UNUSED_KSYMS with CONFIG_THINLTO is really slow because here most of the time is spent in the final link (especially when you have many CPU cores to do the earlier bits quickly), but then it does the link twice. > BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)? > ( Did not look or check for it. ) No, in mainline, HAVE_LD_DEAD_CODE_DATA_ELIMINATION is currently only selected on MIPS and PowerPC. I only sent experimental patches to enable it on arm64 and m68k, but have not tried booting them. If you select the symbol on x86, you should see similar results. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-26 8:15 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-25 11:20 [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Arnd Bergmann 2021-02-25 11:20 ` Arnd Bergmann 2021-02-25 20:16 ` Kees Cook 2021-02-25 20:16 ` Kees Cook 2021-02-26 0:36 ` Sedat Dilek 2021-02-26 0:36 ` Sedat Dilek 2021-02-26 8:14 ` Arnd Bergmann [this message] 2021-02-26 8:14 ` Arnd Bergmann 2021-02-26 9:05 ` Sedat Dilek 2021-02-26 9:05 ` Sedat Dilek 2021-02-26 9:51 ` Arnd Bergmann 2021-02-26 9:51 ` Arnd Bergmann 2021-02-26 10:02 ` Sedat Dilek 2021-02-26 10:02 ` Sedat Dilek 2021-02-27 20:13 ` Sedat Dilek 2021-02-26 21:13 ` Fangrui Song 2021-02-26 21:13 ` Fangrui Song 2021-02-27 9:49 ` Arnd Bergmann 2021-02-27 9:49 ` Arnd Bergmann 2021-03-01 1:11 ` Nicholas Piggin 2021-03-01 1:11 ` Nicholas Piggin 2021-03-10 20:49 ` Masahiro Yamada 2021-03-10 20:49 ` Masahiro Yamada 2021-03-10 21:08 ` Arnd Bergmann 2021-03-10 21:08 ` Arnd Bergmann 2021-03-10 21:24 ` Sedat Dilek 2021-03-10 21:24 ` Sedat Dilek 2021-03-10 21:47 ` Nicolas Pitre 2021-03-10 21:47 ` Nicolas Pitre 2021-03-10 21:57 ` Sedat Dilek 2021-03-10 21:57 ` Sedat Dilek 2021-03-10 22:02 ` Nick Desaulniers 2021-03-10 22:02 ` Nick Desaulniers 2021-03-10 22:08 ` Nicolas Pitre 2021-03-10 22:08 ` Nicolas Pitre 2021-03-10 22:29 ` Fangrui Song 2021-03-10 22:29 ` Fangrui Song 2021-03-10 21:45 ` Rasmus Villemoes 2021-03-10 21:45 ` Rasmus Villemoes 2021-03-10 21:19 ` Nicolas Pitre 2021-03-10 21:19 ` Nicolas Pitre 2021-03-10 22:42 ` Fangrui Song 2021-03-10 22:42 ` Fangrui Song 2021-03-17 14:37 ` Catalin Marinas 2021-03-17 14:37 ` Catalin Marinas 2021-03-17 16:18 ` Catalin Marinas 2021-03-17 16:18 ` Catalin Marinas 2021-03-18 8:41 ` Arnd Bergmann 2021-03-18 8:41 ` Arnd Bergmann 2021-03-19 12:25 ` Catalin Marinas 2021-03-19 12:25 ` Catalin Marinas 2021-03-19 14:01 ` Arnd Bergmann 2021-03-19 14:01 ` 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=CAK8P3a1QmS6g3cHTR93wWPkKs8vaP6RJEb8nZbTMLX+xphLJRw@mail.gmail.com \ --to=arnd@kernel.org \ --cc=ardb@kernel.org \ --cc=arnd@arndb.de \ --cc=ascull@google.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=clang-built-linux@googlegroups.com \ --cc=dbrazdil@google.com \ --cc=geert+renesas@glider.be \ --cc=ionela.voinescu@arm.com \ --cc=keescook@chromium.org \ --cc=kristina.martsenko@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=nathan@kernel.org \ --cc=ndesaulniers@google.com \ --cc=sedat.dilek@gmail.com \ --cc=vincenzo.frascino@arm.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.