linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: dedekind1@gmail.com
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	MTD list <linux-mtd@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] do not select KALLSYMS_ALL
Date: Fri, 01 Apr 2011 16:34:42 +0100	[thread overview]
Message-ID: <4D95F092.4080604@grupopie.com> (raw)
In-Reply-To: <1301670104.2789.94.camel@localhost>

Artem Bityutskiy wrote:
> On Fri, 2011-04-01 at 17:56 +0300, Artem Bityutskiy wrote:
>> Well, ok, I've measured how much is this "a lot". On an embedded arm
>> platform this makes the kernel only 1.5% larger. 
> 
> But in absolute numbers this is 70KiB in my case, which is indeed
> considerable amount. So, I agree that it makes sense to keep this as a
> separate option.

Yes, and this depends a lot on the kernel configuration options you've
selected (and that 1.5% of the kernel size, might be 50%~100% of the
kallsyms table).

IIRC, I had configurations where the KALLSYMS_ALL option was increasing
the kallsyms table from something like 150kB to above 500kB (before
compression). This was a long time ago though and I can't say exactly
what was the configuration that made this happen.

As for the CONFIG_KALLSYMS_EXTRA_PASS, I think the original idea (it was
not mine) was that it should be off by default and then the user would
need to turn it on when something went wrong.

With an automatic makefile mechanism, the problem would go unnoticed and
it just wouldn't be fixed, increasing the kernel compile time for
everyone who hits the same troublesome configuration.

-- 
Paulo Marques - www.grupopie.com

"As far as we know, our computer has never had an undetected error."
Weisert

  parent reply	other threads:[~2011-04-01 15:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30  8:40 [PATCH 0/2] do not select KALLSYMS_ALL Artem Bityutskiy
2011-03-30  8:40 ` [PATCH 1/2] UBIFS: " Artem Bityutskiy
2011-03-30 22:41   ` Randy Dunlap
2011-03-31  6:29     ` Artem Bityutskiy
2011-03-30  8:40 ` [PATCH 2/2] UBI: " Artem Bityutskiy
2011-03-30 22:41   ` Randy Dunlap
2011-03-31 14:18 ` [PATCH 0/2] " Paulo Marques
2011-04-01 14:40   ` Artem Bityutskiy
2011-04-01 14:56   ` Artem Bityutskiy
2011-04-01 15:01     ` Artem Bityutskiy
2011-04-01 15:11       ` Ricard Wanderlof
2011-04-01 15:34       ` Paulo Marques [this message]
2011-04-01 15:42         ` Artem Bityutskiy
2011-04-01 15:54           ` Paulo Marques
2011-04-04  7:12             ` Artem Bityutskiy

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=4D95F092.4080604@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=randy.dunlap@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).