Date: Wed, 23 Jul 2003 15:14:22 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Bernardo Innocenti <bernie@develer.com>
cc: uClinux development list <uclinux-dev@uclinux.org>,
       linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.6 size increase
In-Reply-To: <200307232046.46990.bernie@develer.com>
Message-ID: <Pine.LNX.4.53.0307231507300.16939@chaos>
References: <200307232046.46990.bernie@develer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1258
Lines: 36

On Wed, 23 Jul 2003, Bernardo Innocenti wrote:

> Hello,
>
> code bloat can be very harmful on embedded targets, but it's
> generally inconvenient for any platform. I've measured the
> code increase between 2.4.21 and 2.6.0-test1 on a small
> kernel configuration for ColdFire:
>
>    text    data     bss     dec     hex filename
>  640564   39152  134260  813976   c6b98 linux-2.4.x/linux
                   ^^^^^^
>  845924   51204   78896  976024   ee498 linux-2.5.x/vmlinux

[SNIPPED...]

It looks like a lot of data may have been initialized in the
newer kernel, i.e. int barf = 0; or struct vomit = {0,}.
If they just declared the static data, it would end up in
.bss which is allocated at run-time (and zeroed) and is
not in the kernel image.

You might want to check this out. There is 51204 - 39152 = 12,052
more data, but 134260 - 78896 = 55350 less bss.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/