All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sedat Dilek <sedat.dilek@gmail.com>
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>, 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 ML <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Date: Fri, 26 Feb 2021 01:36:02 +0100	[thread overview]
Message-ID: <CA+icZUUDnKBxkfgOVYDdpA29GnLUTT22mqRNyxQeYmay044ejg@mail.gmail.com> (raw)
In-Reply-To: <20210225112122.2198845-1-arnd@kernel.org>

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?

BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)?
( Did not look or check for it. )

- Sedat -

> 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
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20210225112122.2198845-1-arnd%40kernel.org.

WARNING: multiple messages have this Message-ID (diff)
From: Sedat Dilek <sedat.dilek@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
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,
	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-kernel@lists.infradead.org
Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Date: Fri, 26 Feb 2021 01:36:02 +0100	[thread overview]
Message-ID: <CA+icZUUDnKBxkfgOVYDdpA29GnLUTT22mqRNyxQeYmay044ejg@mail.gmail.com> (raw)
In-Reply-To: <20210225112122.2198845-1-arnd@kernel.org>

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?

BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)?
( Did not look or check for it. )

- Sedat -

> 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
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20210225112122.2198845-1-arnd%40kernel.org.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-02-26  0:37 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 [this message]
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=CA+icZUUDnKBxkfgOVYDdpA29GnLUTT22mqRNyxQeYmay044ejg@mail.gmail.com \
    --to=sedat.dilek@gmail.com \
    --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=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: 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.