[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fdad1e3-1b0c-4292-9bb1-2f7654d9b816@t-8ch.de>
Date: Mon, 25 Nov 2024 16:46:53 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Masahiro Yamada <masahiroy@...nel.org>, linux-kernel@...r.kernel.org, Nicolas Schier <nicolas@...sle.eu>,
linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] kconfig: prefer toolchain default for debug information
choice
Hi Nathan,
On 2024-11-25 07:52:51-0700, Nathan Chancellor wrote:
> On Sun, Nov 24, 2024 at 04:58:04PM +0100, Thomas Weißschuh wrote:
> > Kconfig by default chooses the first entry of a choice setting.
> > For the "debug information" choice this is DEBUG_INFO_NONE which
> > disables debug information completely.
> >
> > The kconfig choice itself recommends to use "Toolchain default":
> >
> > Choose which version of DWARF debug info to emit. If unsure,
> > select "Toolchain default".
> >
> > Align the actual configuration with the recommendation by providing an
> > explicit default.
> >
> > This also enables more codepaths from allmodconfig/allyesconfig which
> > depend on debug information being available.
> >
> > Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> > ---
> > lib/Kconfig.debug | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 5d9eca035d470f7ba0c5ff932c37fd5869174269..0aefcd103d9012cd8067e5594404358b0e977644 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -240,6 +240,7 @@ config AS_HAS_NON_CONST_ULEB128
> > choice
> > prompt "Debug information"
> > depends on DEBUG_KERNEL
> > + default DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
> > help
> > Selecting something other than "None" results in a kernel image
> > that will include debugging info resulting in a larger kernel image.
> >
> > ---
> > base-commit: 9f16d5e6f220661f73b36a4be1b21575651d8833
> > change-id: 20241124-kbuild-allconfig_debug_info-f7449ba15be6
> >
> > Best regards,
> > --
> > Thomas Weißschuh <linux@...ssschuh.net>
> >
>
> I am not the biggest fan of this because it appears to have around a 5%
> penalty in compilation times when I benchmarked building allmodconfig
> with and without this change.
>
> With LLVM 19.1.4:
>
> Benchmark 1: DEBUG_INFO_NONE
> Time (mean ± σ): 715.858 s ± 0.531 s [User: 38038.311 s, System: 3718.784 s]
> Range (min … max): 715.271 s … 716.307 s 3 runs
>
> Benchmark 2: DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
> Time (mean ± σ): 760.749 s ± 0.172 s [User: 40699.800 s, System: 3817.819 s]
> Range (min … max): 760.617 s … 760.943 s 3 runs
>
> Summary
> DEBUG_INFO_NONE ran
> 1.06 ± 0.00 times faster than DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
>
> With GCC 14.2.0:
>
> Benchmark 1: DEBUG_INFO_NONE
> Time (mean ± σ): 830.524 s ± 0.342 s [User: 43901.642 s, System: 4515.917 s]
> Range (min … max): 830.135 s … 830.777 s 3 runs
>
> Benchmark 2: DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
> Time (mean ± σ): 873.663 s ± 0.150 s [User: 46102.416 s, System: 4968.065 s]
> Range (min … max): 873.565 s … 873.836 s 3 runs
>
> Summary
> DEBUG_INFO_NONE ran
> 1.05 ± 0.00 times faster than DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
>
> I understand the desire to have CONFIG_DEBUG_INFO_BTF be selected with
> allmodconfig for the sake of coverage but that is going to add up for
> builders doing many builds a day.
No argument on the increased cost.
But it's called "allyesconfig" not "ciconfig".
I do realize that technically it is a Kconfig "choice" which
does not have a "yes" answer. However I think it does fit the spirit.
> Maybe we could add a fragment to kernel/configs for easily flipping
> this? Another alternative that I have thought about recently is allowing
> developers to specify a directory that holds out of tree config
> fragments (KBUILD_FRAGMENTS_DIR?) that would be searched like
> kernel/configs and arch/*/configs, so that people could maintain their
> own fragments for easily doing something like:
>
> allmodconfig debug_info_btf.config
>
> during configuration. Regardless though, if others find this new default
> desirable, I am fine with it.
The same could be used by the CI setups :-)
There should be less CI setups than regular developers, they known more
about special or expensive configuration quirks and they should already
have logic to filter and customize build configurations.
While I'm arguing here to accomodate for my personal laziness, I also do
think that these are generally valid arguments.
But if there if it's not convincing enough, I'll drop it.
The out of tree fragments idea sounds personally useful but a bit
inconsistent with the rest of kbuild.
AFAIK there is nothing similar; for thing like CFLAGS etc.
Thomas
Powered by blists - more mailing lists