Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
* Linus Torvalds wrote:
> On Tue, Feb 4, 2014 at 1:08 AM, Ingo Molnar wrote:
> >
> > config SAVE_TIME_AND_DISK_SPACE
> > bool "Faster and leaner build object files: compile without debug
> > info"
> > default y
>
> Thinking about it, we already have this. It's called "CONFIG_COMPILE_TEST".
>
> It very much gets set by all{yes,mod}config, and it also says "we're
> interested in testing the compile, not so much running the result".
>
> So let's just make the DEBUG_INFO depend on !COMPILE_TEST.
>
> Trivial oneliner patch (independent of the discussion about improving
> the documentation), so I'll just apply it.
>
> I can't imagine that this would be controversial:
>
>config DEBUG_INFO
> bool "Compile the kernel with debug info"
> - depends on DEBUG_KERNEL
> + depends on DEBUG_KERNEL && !COMPILE_TEST
> help
>
> Hm?
Fully agreed.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Tue, Feb 4, 2014 at 9:32 AM, Andi Kleen wrote:
>
> I have used debug info on allyesconfig in the past to run statistics
> on the resulting binary. It's still useful, even though quite slow.
> Make it depend on !EXPERT or somesuch? I agree for normal usages it's fine.
EXPERT is useless, people set it randomly.
I'd suggest that for any statistics gathering, you just disable
COMPILE_TEST. You can do that by just editing the .config file after
doing the allyesconfig, or by pre-seeding the allyesconfig with
COMPILE_TEST disabled.
Your use-case is rather special, after all. I do *not* believe that we
should make one of the goals of "make all{yes,mod}config" be that kind
of odd specialized thing.
> BTW you probably also want to do the same for the x86 instruction
> decoder test. It seems to be the biggest compile time waster in
> allyesconfig and I usually disable it too.
Agreed, that should be disabled too by default. Although in that case
I think the COMPILE_TEST combination makes more sense, since it's a
coverage issue.
Suggestions for symbols?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
Linus Torvalds writes: > > Trivial oneliner patch (independent of the discussion about improving > the documentation), so I'll just apply it. > > I can't imagine that this would be controversial: > >config DEBUG_INFO > bool "Compile the kernel with debug info" > - depends on DEBUG_KERNEL > + depends on DEBUG_KERNEL && !COMPILE_TEST > help > > Hm? I have used debug info on allyesconfig in the past to run statistics on the resulting binary. It's still useful, even though quite slow. Make it depend on !EXPERT or somesuch? I agree for normal usages it's fine. BTW you probably also want to do the same for the x86 instruction decoder test. It seems to be the biggest compile time waster in allyesconfig and I usually disable it too. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Tue, Feb 4, 2014 at 1:08 AM, Ingo Molnar wrote:
>
> config SAVE_TIME_AND_DISK_SPACE
> bool "Faster and leaner build object files: compile without debug
> info"
> default y
Thinking about it, we already have this. It's called "CONFIG_COMPILE_TEST".
It very much gets set by all{yes,mod}config, and it also says "we're
interested in testing the compile, not so much running the result".
So let's just make the DEBUG_INFO depend on !COMPILE_TEST.
Trivial oneliner patch (independent of the discussion about improving
the documentation), so I'll just apply it.
I can't imagine that this would be controversial:
config DEBUG_INFO
bool "Compile the kernel with debug info"
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL && !COMPILE_TEST
help
Hm?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
* David Rientjes wrote: > On Mon, 3 Feb 2014, Andrew Morton wrote: > > > > > How do you define "huge bloat" if the size of vmlinux doesn't increase? > > > > > > Don't be silly. The size of all the object files increase *hugely*. > > > > yup, I disable this in my allmodconfig testing, to great effect. > > > > That being said, I do think the text should make clear that the bloat > > is a compile-time impact and not a runtime one. Something like > > > > --- > > a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix > > +++ a/lib/Kconfig.debug > > @@ -128,9 +128,9 @@ config DEBUG_INFO > > tools like crash, kgdb, LKCD, gdb, etc on the kernel. > > > > If you only want to have resolved symbols in kernel traces and > > - are not going to need support for those tools above, you don't need > > - to enable this as it is a huge bloat and build slowdown; > > - enable CONFIG_KALLSYMS instead. > > + are not going to need support for the above tools, you don't need > > + to enable this. It hugely bloat object files' on-disk sizes and slows > > + the build. Enable CONFIG_KALLSYMS instead. > > > > If unsure, say N. > > > > Um, I still don't think this is right since > CONFIG_DEBUG_INFO_REDUCED requires you to say yes here and that > config option actually specifies the tools for which it is > effective. Are you suggesting that we decouple CONFIG_DEBUG_INFO > from CONFIG_DEBUG_INFO_REDUCED and make CONFIG_DEBUG_INFO select the > reduced variant? Or... what? I think the right solution is what I suggested in another recent discussion: "So to reign in debuginfo in allyesconfig/allmodconfig builds we could do something like: config SAVE_TIME_AND_DISK_SPACE bool "Faster and leaner build object files: compile without debug info" default y choice prompt "Choose DEBUGINFO bloat level" depends on !SAVE_TIME_AND_DISK_SPACE default DEBUG_INFO_REDUCED help This option allows to select the debuginfo model. config DEBUG_INFO_REDUCED bool "Reduced amount of debugging information, 4x regular .o size" config DEBUG_INFO bool "Full debuginfo, 10x regular .o size, 'planet killer' version" endchoice That would default to Y and would disable debuginfo by default." Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
* David Rientjes rient...@google.com wrote: On Mon, 3 Feb 2014, Andrew Morton wrote: How do you define huge bloat if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. yup, I disable this in my allmodconfig testing, to great effect. That being said, I do think the text should make clear that the bloat is a compile-time impact and not a runtime one. Something like --- a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix +++ a/lib/Kconfig.debug @@ -128,9 +128,9 @@ config DEBUG_INFO tools like crash, kgdb, LKCD, gdb, etc on the kernel. If you only want to have resolved symbols in kernel traces and - are not going to need support for those tools above, you don't need - to enable this as it is a huge bloat and build slowdown; - enable CONFIG_KALLSYMS instead. + are not going to need support for the above tools, you don't need + to enable this. It hugely bloat object files' on-disk sizes and slows + the build. Enable CONFIG_KALLSYMS instead. If unsure, say N. Um, I still don't think this is right since CONFIG_DEBUG_INFO_REDUCED requires you to say yes here and that config option actually specifies the tools for which it is effective. Are you suggesting that we decouple CONFIG_DEBUG_INFO from CONFIG_DEBUG_INFO_REDUCED and make CONFIG_DEBUG_INFO select the reduced variant? Or... what? I think the right solution is what I suggested in another recent discussion: So to reign in debuginfo in allyesconfig/allmodconfig builds we could do something like: config SAVE_TIME_AND_DISK_SPACE bool Faster and leaner build object files: compile without debug info default y choice prompt Choose DEBUGINFO bloat level depends on !SAVE_TIME_AND_DISK_SPACE default DEBUG_INFO_REDUCED help This option allows to select the debuginfo model. config DEBUG_INFO_REDUCED bool Reduced amount of debugging information, 4x regular .o size config DEBUG_INFO bool Full debuginfo, 10x regular .o size, 'planet killer' version endchoice That would default to Y and would disable debuginfo by default. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Tue, Feb 4, 2014 at 1:08 AM, Ingo Molnar mi...@kernel.org wrote:
config SAVE_TIME_AND_DISK_SPACE
bool Faster and leaner build object files: compile without debug
info
default y
Thinking about it, we already have this. It's called CONFIG_COMPILE_TEST.
It very much gets set by all{yes,mod}config, and it also says we're
interested in testing the compile, not so much running the result.
So let's just make the DEBUG_INFO depend on !COMPILE_TEST.
Trivial oneliner patch (independent of the discussion about improving
the documentation), so I'll just apply it.
I can't imagine that this would be controversial:
config DEBUG_INFO
bool Compile the kernel with debug info
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL !COMPILE_TEST
help
Hm?
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
Linus Torvalds torva...@linux-foundation.org writes: Trivial oneliner patch (independent of the discussion about improving the documentation), so I'll just apply it. I can't imagine that this would be controversial: config DEBUG_INFO bool Compile the kernel with debug info - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL !COMPILE_TEST help Hm? I have used debug info on allyesconfig in the past to run statistics on the resulting binary. It's still useful, even though quite slow. Make it depend on !EXPERT or somesuch? I agree for normal usages it's fine. BTW you probably also want to do the same for the x86 instruction decoder test. It seems to be the biggest compile time waster in allyesconfig and I usually disable it too. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Tue, Feb 4, 2014 at 9:32 AM, Andi Kleen a...@firstfloor.org wrote:
I have used debug info on allyesconfig in the past to run statistics
on the resulting binary. It's still useful, even though quite slow.
Make it depend on !EXPERT or somesuch? I agree for normal usages it's fine.
EXPERT is useless, people set it randomly.
I'd suggest that for any statistics gathering, you just disable
COMPILE_TEST. You can do that by just editing the .config file after
doing the allyesconfig, or by pre-seeding the allyesconfig with
COMPILE_TEST disabled.
Your use-case is rather special, after all. I do *not* believe that we
should make one of the goals of make all{yes,mod}config be that kind
of odd specialized thing.
BTW you probably also want to do the same for the x86 instruction
decoder test. It seems to be the biggest compile time waster in
allyesconfig and I usually disable it too.
Agreed, that should be disabled too by default. Although in that case
I think the COMPILE_TEST combination makes more sense, since it's a
coverage issue.
Suggestions for symbols?
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
* Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Feb 4, 2014 at 1:08 AM, Ingo Molnar mi...@kernel.org wrote:
config SAVE_TIME_AND_DISK_SPACE
bool Faster and leaner build object files: compile without debug
info
default y
Thinking about it, we already have this. It's called CONFIG_COMPILE_TEST.
It very much gets set by all{yes,mod}config, and it also says we're
interested in testing the compile, not so much running the result.
So let's just make the DEBUG_INFO depend on !COMPILE_TEST.
Trivial oneliner patch (independent of the discussion about improving
the documentation), so I'll just apply it.
I can't imagine that this would be controversial:
config DEBUG_INFO
bool Compile the kernel with debug info
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL !COMPILE_TEST
help
Hm?
Fully agreed.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, Feb 03, 2014 at 02:57:18PM -0800, Andrew Morton wrote: > On Mon, 3 Feb 2014 14:47:15 -0800 Linus Torvalds > wrote: > > > On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes wrote: > > > > > > How do you define "huge bloat" if the size of vmlinux doesn't increase? > > > > Don't be silly. The size of all the object files increase *hugely*. > > yup, I disable this in my allmodconfig testing, to great effect. > > That being said, I do think the text should make clear that the bloat > is a compile-time impact and not a runtime one. Something like > > --- > a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix > +++ a/lib/Kconfig.debug > @@ -128,9 +128,9 @@ config DEBUG_INFO > tools like crash, kgdb, LKCD, gdb, etc on the kernel. > > If you only want to have resolved symbols in kernel traces and > - are not going to need support for those tools above, you don't need > - to enable this as it is a huge bloat and build slowdown; > - enable CONFIG_KALLSYMS instead. > + are not going to need support for the above tools, you don't need > + to enable this. It hugely bloat object files' on-disk sizes and slows > + the build. Enable CONFIG_KALLSYMS instead. Yes, this is better. Andrew, can you add that or you want me to send a new version? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014, Andrew Morton wrote: > > > How do you define "huge bloat" if the size of vmlinux doesn't increase? > > > > Don't be silly. The size of all the object files increase *hugely*. > > yup, I disable this in my allmodconfig testing, to great effect. > > That being said, I do think the text should make clear that the bloat > is a compile-time impact and not a runtime one. Something like > > --- > a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix > +++ a/lib/Kconfig.debug > @@ -128,9 +128,9 @@ config DEBUG_INFO > tools like crash, kgdb, LKCD, gdb, etc on the kernel. > > If you only want to have resolved symbols in kernel traces and > - are not going to need support for those tools above, you don't need > - to enable this as it is a huge bloat and build slowdown; > - enable CONFIG_KALLSYMS instead. > + are not going to need support for the above tools, you don't need > + to enable this. It hugely bloat object files' on-disk sizes and slows > + the build. Enable CONFIG_KALLSYMS instead. > > If unsure, say N. > Um, I still don't think this is right since CONFIG_DEBUG_INFO_REDUCED requires you to say yes here and that config option actually specifies the tools for which it is effective. Are you suggesting that we decouple CONFIG_DEBUG_INFO from CONFIG_DEBUG_INFO_REDUCED and make CONFIG_DEBUG_INFO select the reduced variant? Or... what? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014 14:47:15 -0800 Linus Torvalds wrote: > On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes wrote: > > > > How do you define "huge bloat" if the size of vmlinux doesn't increase? > > Don't be silly. The size of all the object files increase *hugely*. yup, I disable this in my allmodconfig testing, to great effect. That being said, I do think the text should make clear that the bloat is a compile-time impact and not a runtime one. Something like --- a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix +++ a/lib/Kconfig.debug @@ -128,9 +128,9 @@ config DEBUG_INFO tools like crash, kgdb, LKCD, gdb, etc on the kernel. If you only want to have resolved symbols in kernel traces and - are not going to need support for those tools above, you don't need - to enable this as it is a huge bloat and build slowdown; - enable CONFIG_KALLSYMS instead. + are not going to need support for the above tools, you don't need + to enable this. It hugely bloat object files' on-disk sizes and slows + the build. Enable CONFIG_KALLSYMS instead. If unsure, say N. _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes wrote: > > How do you define "huge bloat" if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. This is my fs/builtin.o in my normal config: -rw-rw-r--. 1 torvalds torvalds 2838613 Feb 3 14:32 fs/built-in.o and with the *reduced* debug info, ie .config diff as follows: +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_INFO_REDUCED=y I get this: -rw-rw-r--. 1 torvalds torvalds 11793317 Feb 3 14:33 fs/built-in.o iow, that "reduced" debug info is still more than 4x bigger than a non-debug-info kernel. David, if you don't think that debug-info bloats the build, you're in huge *huge* denial. CONFIG_DEBUG_INFO (even with the "reduced" thing) is ABSOLUTELY HORRIBLE CRAP. > Would some people consider that to be acceptable but now mysteriously > confused because we don't know what "huge bloat" you're referring to? That >4x size increase doesn't match your idea of "huge bloat"? The object files being much bigger really does screw you especially on laptops that often have less memory and less capable IO subsystems. The final links in particular tend to be much bigger and use much more memory. I suspect a lot of people are in denial about just how *horrible* the overhead of debug builds are. And yeah, if you have oodles of memory to cache things, it's not too bad. But you really want to have *lots* of memory, because otherwise you won't be caching all those object files in RAM, and your build easily becomes IO bound at link time. A factor of four size difference will not be helping your poor slow laptop disk.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014, Borislav Petkov wrote: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index dbf94a7d25a8..9095c2078095 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -126,7 +126,11 @@ config DEBUG_INFO > This adds debug symbols to the kernel and modules (gcc -g), and > is needed if you intend to use kernel crashdump or binary object > tools like crash, kgdb, LKCD, gdb, etc on the kernel. > - Say Y here only if you plan to debug the kernel. > + > + If you only want to have resolved symbols in kernel traces and > + are not going to need support for those tools above, you don't need > + to enable this as it is a huge bloat and build slowdown; How do you define "huge bloat" if the size of vmlinux doesn't increase? Would some people consider that to be acceptable but now mysteriously confused because we don't know what "huge bloat" you're referring to? It also begs the question about the meaning of DEBUG_INFO_REDUCED and this comment doesn't even allow us to see that it's an option. So this doesn't look good. > + enable CONFIG_KALLSYMS instead. > > If unsure, say N. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
From: Borislav Petkov Hold down when it makes sense to enable CONFIG_DEBUG_INFO and when CONFIG_KALLSYMS suffices. Signed-off-by: Borislav Petkov Link: http://lkml.kernel.org/r/CA%2B55aFw_xs1tUteDrXz21QZB7BFk5p%2BF5NZ-SpV=cuvjefw...@mail.gmail.com Cc: Andrew Morton Cc: Linus Torvalds --- lib/Kconfig.debug | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index dbf94a7d25a8..9095c2078095 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -126,7 +126,11 @@ config DEBUG_INFO This adds debug symbols to the kernel and modules (gcc -g), and is needed if you intend to use kernel crashdump or binary object tools like crash, kgdb, LKCD, gdb, etc on the kernel. - Say Y here only if you plan to debug the kernel. + + If you only want to have resolved symbols in kernel traces and + are not going to need support for those tools above, you don't need + to enable this as it is a huge bloat and build slowdown; + enable CONFIG_KALLSYMS instead. If unsure, say N. -- 1.8.5.2.192.g7794a68 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
From: Borislav Petkov b...@suse.de Hold down when it makes sense to enable CONFIG_DEBUG_INFO and when CONFIG_KALLSYMS suffices. Signed-off-by: Borislav Petkov b...@suse.de Link: http://lkml.kernel.org/r/CA%2B55aFw_xs1tUteDrXz21QZB7BFk5p%2BF5NZ-SpV=cuvjefw...@mail.gmail.com Cc: Andrew Morton a...@linux-foundation.org Cc: Linus Torvalds torva...@linux-foundation.org --- lib/Kconfig.debug | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index dbf94a7d25a8..9095c2078095 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -126,7 +126,11 @@ config DEBUG_INFO This adds debug symbols to the kernel and modules (gcc -g), and is needed if you intend to use kernel crashdump or binary object tools like crash, kgdb, LKCD, gdb, etc on the kernel. - Say Y here only if you plan to debug the kernel. + + If you only want to have resolved symbols in kernel traces and + are not going to need support for those tools above, you don't need + to enable this as it is a huge bloat and build slowdown; + enable CONFIG_KALLSYMS instead. If unsure, say N. -- 1.8.5.2.192.g7794a68 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014, Borislav Petkov wrote: diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index dbf94a7d25a8..9095c2078095 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -126,7 +126,11 @@ config DEBUG_INFO This adds debug symbols to the kernel and modules (gcc -g), and is needed if you intend to use kernel crashdump or binary object tools like crash, kgdb, LKCD, gdb, etc on the kernel. - Say Y here only if you plan to debug the kernel. + + If you only want to have resolved symbols in kernel traces and + are not going to need support for those tools above, you don't need + to enable this as it is a huge bloat and build slowdown; How do you define huge bloat if the size of vmlinux doesn't increase? Would some people consider that to be acceptable but now mysteriously confused because we don't know what huge bloat you're referring to? It also begs the question about the meaning of DEBUG_INFO_REDUCED and this comment doesn't even allow us to see that it's an option. So this doesn't look good. + enable CONFIG_KALLSYMS instead. If unsure, say N. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes rient...@google.com wrote: How do you define huge bloat if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. This is my fs/builtin.o in my normal config: -rw-rw-r--. 1 torvalds torvalds 2838613 Feb 3 14:32 fs/built-in.o and with the *reduced* debug info, ie .config diff as follows: +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_INFO_REDUCED=y I get this: -rw-rw-r--. 1 torvalds torvalds 11793317 Feb 3 14:33 fs/built-in.o iow, that reduced debug info is still more than 4x bigger than a non-debug-info kernel. David, if you don't think that debug-info bloats the build, you're in huge *huge* denial. CONFIG_DEBUG_INFO (even with the reduced thing) is ABSOLUTELY HORRIBLE CRAP. Would some people consider that to be acceptable but now mysteriously confused because we don't know what huge bloat you're referring to? That 4x size increase doesn't match your idea of huge bloat? The object files being much bigger really does screw you especially on laptops that often have less memory and less capable IO subsystems. The final links in particular tend to be much bigger and use much more memory. I suspect a lot of people are in denial about just how *horrible* the overhead of debug builds are. And yeah, if you have oodles of memory to cache things, it's not too bad. But you really want to have *lots* of memory, because otherwise you won't be caching all those object files in RAM, and your build easily becomes IO bound at link time. A factor of four size difference will not be helping your poor slow laptop disk.. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014 14:47:15 -0800 Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes rient...@google.com wrote: How do you define huge bloat if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. yup, I disable this in my allmodconfig testing, to great effect. That being said, I do think the text should make clear that the bloat is a compile-time impact and not a runtime one. Something like --- a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix +++ a/lib/Kconfig.debug @@ -128,9 +128,9 @@ config DEBUG_INFO tools like crash, kgdb, LKCD, gdb, etc on the kernel. If you only want to have resolved symbols in kernel traces and - are not going to need support for those tools above, you don't need - to enable this as it is a huge bloat and build slowdown; - enable CONFIG_KALLSYMS instead. + are not going to need support for the above tools, you don't need + to enable this. It hugely bloat object files' on-disk sizes and slows + the build. Enable CONFIG_KALLSYMS instead. If unsure, say N. _ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014, Andrew Morton wrote: How do you define huge bloat if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. yup, I disable this in my allmodconfig testing, to great effect. That being said, I do think the text should make clear that the bloat is a compile-time impact and not a runtime one. Something like --- a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix +++ a/lib/Kconfig.debug @@ -128,9 +128,9 @@ config DEBUG_INFO tools like crash, kgdb, LKCD, gdb, etc on the kernel. If you only want to have resolved symbols in kernel traces and - are not going to need support for those tools above, you don't need - to enable this as it is a huge bloat and build slowdown; - enable CONFIG_KALLSYMS instead. + are not going to need support for the above tools, you don't need + to enable this. It hugely bloat object files' on-disk sizes and slows + the build. Enable CONFIG_KALLSYMS instead. If unsure, say N. Um, I still don't think this is right since CONFIG_DEBUG_INFO_REDUCED requires you to say yes here and that config option actually specifies the tools for which it is effective. Are you suggesting that we decouple CONFIG_DEBUG_INFO from CONFIG_DEBUG_INFO_REDUCED and make CONFIG_DEBUG_INFO select the reduced variant? Or... what? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, Feb 03, 2014 at 02:57:18PM -0800, Andrew Morton wrote: On Mon, 3 Feb 2014 14:47:15 -0800 Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes rient...@google.com wrote: How do you define huge bloat if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. yup, I disable this in my allmodconfig testing, to great effect. That being said, I do think the text should make clear that the bloat is a compile-time impact and not a runtime one. Something like --- a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix +++ a/lib/Kconfig.debug @@ -128,9 +128,9 @@ config DEBUG_INFO tools like crash, kgdb, LKCD, gdb, etc on the kernel. If you only want to have resolved symbols in kernel traces and - are not going to need support for those tools above, you don't need - to enable this as it is a huge bloat and build slowdown; - enable CONFIG_KALLSYMS instead. + are not going to need support for the above tools, you don't need + to enable this. It hugely bloat object files' on-disk sizes and slows + the build. Enable CONFIG_KALLSYMS instead. Yes, this is better. Andrew, can you add that or you want me to send a new version? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
