From: Matt Mackall <mpm@selenic.com>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: Bloat report 2.6.3 -> 2.6.4
Date: Sat, 13 Mar 2004 11:33:32 -0600 [thread overview]
Message-ID: <20040313173331.GO20174@waste.org> (raw)
In-Reply-To: <20040313170839.GV14833@fs.tum.de>
On Sat, Mar 13, 2004 at 06:08:40PM +0100, Adrian Bunk wrote:
> On Fri, Mar 12, 2004 at 05:53:49PM -0600, Matt Mackall wrote:
> > On Fri, Mar 12, 2004 at 03:22:06PM -0800, Andrew Morton wrote:
> > > Matt Mackall <mpm@selenic.com> wrote:
> > > >
> > > > 2.6.3 -> 2.6.4
> > > >
> > > > text data bss dec hex filename
> > > > 3313135 660247 162472 4135854 3f1bae vmlinux-2.6.3-c2.6.3
> > > > 3342019 664154 162344 4168517 3f9b45 vmlinux-2.6.4-c2.6.3
> > > >
> > > > [ Results of size <a> <b>. -c2.6.3 means both kernel images were built
> > > > with the 2.6.3 defconfig.
> > >
> > > But defconfig was changed between 2.6.3 and 2.6.4.
> >
> > Yes, and I'm attempting to compensate for that because defconfig
> > changes tend to overwhelm other stuff in the results.
> >
> > My strategy here doesn't work as well as I'd hoped. I'm taking the
> > defconfig from the previous kernel and then running yes "" | make
> > oldconfig, which sets any new symbols to their defaults. So this deals
> > with case where existing symbols change defaults, but doesn't address
> > new symbols at all.
> >
> > And what's happening with some of the new symbols is that they're off
> > in defconfig but on in Kconfig. So I need to come up with a way to
> > take the old defconfig and merge in new symbols from the new
> > defconfig. Then throw it at make oldconfig to drop out any obsolete
> > symbols.
>
> You have to realize that your "automated scheme to measure the growth of
> the kernel" doesn't work as you might have expected.
>
> As an example, consider the following option gets added:
>
> config ACPI_NEW_OPTION
> bool "new option"
> depends on ACPI
> default y
> help
> This option adds support for $new_feature.
> It enlarges your kernel by about 100k.
> It's save to say Y.
>
>
> In your size metric, this option would be pure "bloat".
I actually did explicitly note this problem in the part you clipped.
But I think it's fair to say that new features that are on by default
are in fact bloat in some sense.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
next prev parent reply other threads:[~2004-03-13 17:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-12 20:44 Bloat report 2.6.3 -> 2.6.4 Matt Mackall
2004-03-12 23:22 ` Andrew Morton
2004-03-12 23:53 ` Matt Mackall
2004-03-13 17:08 ` Adrian Bunk
2004-03-13 17:33 ` Matt Mackall [this message]
2004-03-13 17:57 ` Adrian Bunk
2004-03-13 23:59 ` Matt Mackall
2004-03-14 0:32 ` Adrian Bunk
2004-03-14 0:57 ` Matt Mackall
2004-03-22 22:51 ` Mike Fedyk
2004-03-24 17:22 ` Tim Bird
2004-03-13 22:17 ` Sam Ravnborg
2004-03-14 0:15 ` Matt Mackall
2004-03-14 21:03 ` John Cherry
2004-03-13 23:34 ` Horst von Brand
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=20040313173331.GO20174@waste.org \
--to=mpm@selenic.com \
--cc=akpm@osdl.org \
--cc=bunk@fs.tum.de \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox