From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Ionela Voinescu <ionela.voinescu@arm.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-kernel@vger.kernel.org,
Kristina Martsenko <kristina.martsenko@arm.com>,
Ard Biesheuvel <ardb@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
clang-built-linux@googlegroups.com,
Mark Brown <broonie@kernel.org>, Andrew Scull <ascull@google.com>,
Marc Zyngier <maz@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>,
David Brazdil <dbrazdil@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Date: Thu, 25 Feb 2021 12:16:40 -0800 [thread overview]
Message-ID: <202102251216.935EFD7F@keescook> (raw)
In-Reply-To: <20210225112122.2198845-1-arnd@kernel.org>
On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann 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
>
> I needed a small change to the linker script to get clean randconfig
> builds, but I have not done any meaningful boot testing on it to
> see if it works. If there are no regressions, I wonder whether this
> should be autmatically done for LTO builds, given that it improves
> both kernel size and compile speed.
>
> Link: https://lore.kernel.org/lkml/CAK8P3a05VZ9hSKRzVTxTn+1nf9E+gqebJWTj6N23nfm+ELHt9A@mail.gmail.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@kernel.org>
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>, 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-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com
Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Date: Thu, 25 Feb 2021 12:16:40 -0800 [thread overview]
Message-ID: <202102251216.935EFD7F@keescook> (raw)
In-Reply-To: <20210225112122.2198845-1-arnd@kernel.org>
On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann 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
>
> I needed a small change to the linker script to get clean randconfig
> builds, but I have not done any meaningful boot testing on it to
> see if it works. If there are no regressions, I wonder whether this
> should be autmatically done for LTO builds, given that it improves
> both kernel size and compile speed.
>
> Link: https://lore.kernel.org/lkml/CAK8P3a05VZ9hSKRzVTxTn+1nf9E+gqebJWTj6N23nfm+ELHt9A@mail.gmail.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
next prev parent reply other threads:[~2021-02-25 20:18 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 [this message]
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
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=202102251216.935EFD7F@keescook \
--to=keescook@chromium.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--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=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=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: link
Be 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.