[bernie@develer.com: Kernel 2.6 size increase]

[bernie@develer.com: Kernel 2.6 size increase]

[Christoph Hellwig]

I think this is not only of interest fir the uClinux folks..

----- Forwarded message from Bernardo Innocenti <bernie@develer.com> -----

Date:	Wed, 23 Jul 2003 20:46:46 +0200
From:	Bernardo Innocenti <bernie@develer.com>
Subject: Kernel 2.6 size increase
To:	uClinux development list <uclinux-dev@uclinux.org>
Cc:	linux-kernel@vger.kernel.org

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

I could provide the exact .config file for both kernels to
anybody interested. They are almost the same: no filesystems
except JFFS2, IPv4 and a bunch of small drivers. I have no
SMP, security, futexes, modules and anything else not
strictly needed to execute processes.

I've made a linker map file and compared the size of single
subsystems. These are the the major contributors to the
size increase:

  kernel/   +27KB
  mm/       +14KB
  fs/       +47KB
  drivers/  +35KB
  net/      +64KB

I've digged into net/ with nm -S --size-sort. It seems that
the major increase is caused by net/xfrm/. Could this module
be made optional?

In fs/, almost all modules have got 30-40% bigger, therefore
bloat is probably caused by inlines and macros getting more
complex.

Block drivers and MTD have generally become smaller. Character
devices are responsable for most of the size increase in drivers/.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html


-
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/

----- End forwarded message -----

Re: [bernie@develer.com: Kernel 2.6 size increase]

[Christoph Hellwig]

On Wed, Jul 23, 2003 at 07:53:55PM +0100, Christoph Hellwig wrote:
> I think this is not only of interest fir the uClinux folks..

Sorry, this actually already Cc'ed lkml :)  Still the netdev folks
should read it, too.

Re: [bernie@develer.com: Kernel 2.6 size increase]

[David S. Miller]

On Wed, 23 Jul 2003 19:55:04 +0100
Christoph Hellwig <hch@infradead.org> wrote:

> On Wed, Jul 23, 2003 at 07:53:55PM +0100, Christoph Hellwig wrote:
> > I think this is not only of interest fir the uClinux folks..
> 
> Sorry, this actually already Cc'ed lkml :)  Still the netdev folks
> should read it, too.

Well, we gained some code and a little bit of data, but
the BSS was cut in half which I think deserves noticing :-)

Also, he should analyze the amount of code that actually
gets executed for various tasks, comparing 2.4.x to 2.5.x

I'd take a half-meg code size hit if it meant that all
the normal code paths got cut in half :-)

Re: [bernie@develer.com: Kernel 2.6 size increase]

[Christoph Hellwig]

On Wed, Jul 23, 2003 at 11:58:58AM -0700, David S. Miller wrote:
> > Sorry, this actually already Cc'ed lkml :)  Still the netdev folks
> > should read it, too.
> 
> Well, we gained some code and a little bit of data, but
> the BSS was cut in half which I think deserves noticing :-)
> 
> Also, he should analyze the amount of code that actually
> gets executed for various tasks, comparing 2.4.x to 2.5.x
> 
> I'd take a half-meg code size hit if it meant that all
> the normal code paths got cut in half :-)

half a megabyte more codesize is a lot if you're based on flash.
I know you absolutely disliked Andi's patch to make the xfrm subsystem
optional so we might need find other ways to make the code smaller
on those systems that need it.  Now I could talk a lot but I'm really
no networking insider so it's hard for me to suggest where to start.
I'll rather look at the fs/ issue but it would be nice if networking
folks could do their part, too.

Re: [bernie@develer.com: Kernel 2.6 size increase]

[David S. Miller]

On Wed, 23 Jul 2003 20:06:58 +0100
Christoph Hellwig <hch@infradead.org> wrote:

> I know you absolutely disliked Andi's patch to make the xfrm subsystem
> optional so we might need find other ways to make the code smaller
> on those systems that need it.

I'm willing to reconsider it.

So basically we'd have a CONFIG_NET_XFRM, and things like
AH/ESP/IPCOMP/AH6/ESP6/IPCOMP6 would say "select NET_XFRM"
in the Kconfig where they are selected.

Then when CONFIG_NET_XFRM is not set all the xfrm interfaces
called from non-ipsec non-xfrm source files get NOP versions.

Is this exactly what Andi's patch did?  Just send it on
so we can integrate this.

We actually lost a lot of code in other areas of the networking, for
example Andrew Morton and I made many bogus function inlines
undone because they made the code too large.

Re: [bernie@develer.com: Kernel 2.6 size increase]

[Christoph Hellwig]

On Wed, Jul 23, 2003 at 12:09:01PM -0700, David S. Miller wrote:
> So basically we'd have a CONFIG_NET_XFRM, and things like
> AH/ESP/IPCOMP/AH6/ESP6/IPCOMP6 would say "select NET_XFRM"
> in the Kconfig where they are selected.
> 
> Then when CONFIG_NET_XFRM is not set all the xfrm interfaces
> called from non-ipsec non-xfrm source files get NOP versions.
> 
> Is this exactly what Andi's patch did?  Just send it on
> so we can integrate this.

I think that's what it did modula the select which IIRC wasn't
available back then.  But I guess I'll rather leave this to
Andi.

> We actually lost a lot of code in other areas of the networking, for
> example Andrew Morton and I made many bogus function inlines
> undone because they made the code too large.

That's cool!  Now we just need to find a bunch more regressions
and actually make 2.6 smaller than 2.4 :)  Of course that's true
for the other subsystems, too.