All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>,
	LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
	Richard Weinberger <richard@nod.at>, Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
Date: Tue, 4 Feb 2014 10:08:25 +0100	[thread overview]
Message-ID: <20140204090809.GA19156@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402031532480.7643@chino.kir.corp.google.com>


* David Rientjes <rientjes@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


  reply	other threads:[~2014-02-04  9:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 18:29 [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature Borislav Petkov
2014-02-03 22:00 ` David Rientjes
2014-02-03 22:47   ` Linus Torvalds
2014-02-03 22:57     ` Andrew Morton
2014-02-03 23:34       ` David Rientjes
2014-02-04  9:08         ` Ingo Molnar [this message]
2014-02-04 16:36           ` Linus Torvalds
2014-02-04 17:32             ` Andi Kleen
2014-02-04 18:41               ` Linus Torvalds
2014-02-05  5:51                 ` [PATCH] x86: Disable CONFIG_X86_DECODER_SELFTEST in allmod/allyesconfigs Ingo Molnar
2014-02-05 16:17                   ` Paul Gortmaker
2014-02-05 17:32                     ` Andi Kleen
2014-02-10 13:31                   ` [tip:x86/urgent] x86/debug: " tip-bot for Ingo Molnar
2014-02-11  0:01                   ` [PATCH] x86: " Stephen Rothwell
2014-02-11  7:14                     ` Ingo Molnar
2014-02-05  5:46             ` [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature Ingo Molnar
2014-02-04  4:59       ` Borislav Petkov

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=20140204090809.GA19156@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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.