From: Arnd Bergmann <arnd@kernel.org> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com> Cc: 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-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Date: Thu, 25 Feb 2021 12:20:56 +0100 [thread overview] Message-ID: <20210225112122.2198845-1-arnd@kernel.org> (raw) 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> --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/vmlinux.lds.S | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b94a678afce4..75e13cc52928 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2,6 +2,7 @@ config ARM64 def_bool y select ACPI_CCA_REQUIRED if ACPI + select HAVE_LD_DEAD_CODE_DATA_ELIMINATION select ACPI_GENERIC_GSI if ACPI select ACPI_GTDT if ACPI select ACPI_IORT if ACPI diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index bad2b9eaab22..926cdb597a45 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -217,7 +217,7 @@ SECTIONS INIT_CALLS CON_INITCALL INIT_RAM_FS - *(.init.altinstructions .init.bss .init.bss.*) /* from the EFI stub */ + *(.init.altinstructions .init.data.* .init.bss .init.bss.*) /* from the EFI stub */ } .exit.data : { EXIT_DATA -- 2.29.2
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com> Cc: Mark Rutland <mark.rutland@arm.com>, David Brazdil <dbrazdil@google.com>, Kees Cook <keescook@chromium.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Marc Zyngier <maz@kernel.org>, linux-kernel@vger.kernel.org, Kristina Martsenko <kristina.martsenko@arm.com>, clang-built-linux@googlegroups.com, Mark Brown <broonie@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Andrew Scull <ascull@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Ionela Voinescu <ionela.voinescu@arm.com>, Ard Biesheuvel <ardb@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Date: Thu, 25 Feb 2021 12:20:56 +0100 [thread overview] Message-ID: <20210225112122.2198845-1-arnd@kernel.org> (raw) 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> --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/vmlinux.lds.S | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b94a678afce4..75e13cc52928 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2,6 +2,7 @@ config ARM64 def_bool y select ACPI_CCA_REQUIRED if ACPI + select HAVE_LD_DEAD_CODE_DATA_ELIMINATION select ACPI_GENERIC_GSI if ACPI select ACPI_GTDT if ACPI select ACPI_IORT if ACPI diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index bad2b9eaab22..926cdb597a45 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -217,7 +217,7 @@ SECTIONS INIT_CALLS CON_INITCALL INIT_RAM_FS - *(.init.altinstructions .init.bss .init.bss.*) /* from the EFI stub */ + *(.init.altinstructions .init.data.* .init.bss .init.bss.*) /* from the EFI stub */ } .exit.data : { EXIT_DATA -- 2.29.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2021-02-25 11:22 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-25 11:20 Arnd Bergmann [this message] 2021-02-25 11:20 ` [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION 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 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=20210225112122.2198845-1-arnd@kernel.org \ --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=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.