Re: [uClinux-dev] Kernel 2.6 size increase

Re: [uClinux-dev] Kernel 2.6 size increase

[John Bradford]

> | > >    text    data     bss     dec     hex filename
> | > >  633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os
> | > >  819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os
> | > >  ^^^^^^
> | > >        2.6 still needs a hard diet... :-/
> | >
> | > I did the same observation a few weeks ago on 2.5.74/gcc-2.95.3. I tried
> | > to track down the responsible, to the point that I completely disabled
> | > every driver, networking option and file-system, just to see, and got about
> | > a 550 kB vmlinux compiled with -Os. 550 kB for nothing :-(
> | 
> | Some of the bigger 2.6 additions cannot be configured out.
> | I wish sysfs and the different I/O schedulers could be removed.

I thought that an optimisation for text size in 2.4 had been purposely
taken out of the 2.5 tree, because we expected GCC to do it
automatically by the time 2.6 was released?

> Perhaps after 2.6.n is out and stable for a month or so someone could
> look at the problem. Certainly the various io schedulers are good
> candidates for being optional and/or modules. The problem is that the
> parts which aren't needed aren't large, so you may not gain much.
>
> Clearly you have to have *some* io scheduler

For embedded systems, or anything completely solid state which doesn't
use a traditional spinning-disk-with-moving-heads, you could replace
it with a very simple one, and not loose much performance.

> I'm not sure if sysfs is optional in any meaningful way any more. I
> haven't tried running w/i /proc in a few months, it didn't work when
> I did, but old kernels are old news.

Try compiling out TCP/IP if your application doesn't need it.  A lot
of embedded systems don't.

John.

Re: [uClinux-dev] Kernel 2.6 size increase

[David Woodhouse]

On Fri, 2003-08-08 at 15:37, Bernardo Innocenti wrote:
> So, let's try to remove the block layer from the kernel.
> Do you reckon it would be difficult to do?

Depends how thorough you want to be. I wanted to go the whole way and
actually remove the definition of struct buffer_head, then remove all
the code which would no longer compile at all..

You could be slightly less enthusiastic about it and make life easier
for yourself, I suppose.

-- 
dwmw2

Re: [uClinux-dev] Kernel 2.6 size increase

[Bernardo Innocenti]

David Woodhouse wrote:
> On Tue, 2003-07-29 at 00:02, Bernardo Innocenti wrote:
> 
>>I've read in the Kconfig help that JFFS2 still depends on mtdblock even
>>though it doesn't use it for I/O. I think I've also seen some promise
>>that this dependency will eventually be removed...
> 
> It's already been removed from everything but the Kconfig file... :)

So, let's try to remove the block layer from the kernel.
Do you reckon it would be difficult to do?

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

Re: [uClinux-dev] Kernel 2.6 size increase

[David Woodhouse]

On Tue, 2003-07-29 at 00:02, Bernardo Innocenti wrote:
> I've read in the Kconfig help that JFFS2 still depends on mtdblock even
> though it doesn't use it for I/O. I think I've also seen some promise
> that this dependency will eventually be removed...

It's already been removed from everything but the Kconfig file... :)

-- 
dwmw2

Re: [uClinux-dev] Kernel 2.6 size increase

[Tom Rini]

On Wed, Jul 30, 2003 at 04:49:37AM +0200, Bernardo Innocenti wrote:
> On Wednesday 30 July 2003 00:29, Tom Rini wrote:
> 
> > > Some of the bigger 2.6 additions cannot be configured out.
> > > I wish sysfs and the different I/O schedulers could be removed.
> > >
> > > There are probably many other things mostly useless for embedded
> > > systems that I'm not aware of.
> >
> > Well, from Pat's talk at OLS, it seems like sysfs would be an important
> > part of 'sleep', which is something at least some embedded systems care
> > about.
> 
> I tried stripping sysfs away. I just saved 7KB and got a kernel that
> couldn't boot because root device translation depends on sysfs ;-)

Now that someone has gone down the path (and, thanks for doing it), we
know how much is saved and what needs to be done to get it to work.
Lets just hope it doesn't grow that much more.

> > ... not that 2.6 doesn't need some good pruning options now, but maybe
> > CONFIG_EMBEDDED isn't the right place to put them all.
> 
> In the long term the embedded menu would get cluttered with all kinds
> of disparate options... I don't think I would like it.

Certainly.  I hope to have more time to get the tweaks patch I talked
about in one of the CONFIG_TINY threads a bit further along (1
dependancy left to get right) and at least get some discussion going on
it, but not now.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [uClinux-dev] Kernel 2.6 size increase

[Bernardo Innocenti]

On Wednesday 30 July 2003 00:29, Tom Rini wrote:

> > Some of the bigger 2.6 additions cannot be configured out.
> > I wish sysfs and the different I/O schedulers could be removed.
> >
> > There are probably many other things mostly useless for embedded
> > systems that I'm not aware of.
>
> Well, from Pat's talk at OLS, it seems like sysfs would be an important
> part of 'sleep', which is something at least some embedded systems care
> about.

I tried stripping sysfs away. I just saved 7KB and got a kernel that
couldn't boot because root device translation depends on sysfs ;-)

> ... not that 2.6 doesn't need some good pruning options now, but maybe
> CONFIG_EMBEDDED isn't the right place to put them all.

In the long term the embedded menu would get cluttered with all kinds
of disparate options... I don't think I would like it.

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

Re: [uClinux-dev] Kernel 2.6 size increase

[Tom Rini]

On Tue, Jul 29, 2003 at 11:48:10PM +0100, Alan Cox wrote:
> On Maw, 2003-07-29 at 23:29, Tom Rini wrote:
> > 
> > Well, from Pat's talk at OLS, it seems like sysfs would be an important
> > part of 'sleep', which is something at least some embedded systems care
> > about.
> 
> sysfs is relevant for bigger systems but for small embedded stuff the whole
> PM layer is fairly "so what". At that level your hardware is tightly defined
> and you *know* the power management ordering. Policy becomes critical for 
> performance and gets done at a very fine grained level - things like waking
> up the flash for a read then turning it back off on a timer for example.

And wouldn't it be nice to have one 'policy enforcing tool' or whatever
that you feed it policy_desktop.txt, policy_embedded_in_my_fridge.txt or
policy_enterprise.txt ?

And while you know the ordering for your one board, it's not the same as
that other board there, nor that third board just behind you, and so on.
So getting passed in some sort of tree (or more correctly DAG) and
dealing with it with some more generic code sure sounds nice.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [uClinux-dev] Kernel 2.6 size increase

[Alan Cox]

On Maw, 2003-07-29 at 23:29, Tom Rini wrote:
> 
> Well, from Pat's talk at OLS, it seems like sysfs would be an important
> part of 'sleep', which is something at least some embedded systems care
> about.

sysfs is relevant for bigger systems but for small embedded stuff the whole
PM layer is fairly "so what". At that level your hardware is tightly defined
and you *know* the power management ordering. Policy becomes critical for 
performance and gets done at a very fine grained level - things like waking
up the flash for a read then turning it back off on a timer for example.

Re: [uClinux-dev] Kernel 2.6 size increase

[Tom Rini]

On Thu, Jul 24, 2003 at 10:27:16PM +0200, Bernardo Innocenti wrote:
> On Thursday 24 July 2003 00:27, Willy Tarreau wrote:
> 
> > On Thu, Jul 24, 2003 at 12:07:15AM +0200, Bernardo Innocenti wrote:
> > >    text    data     bss     dec     hex filename
> > >  633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os
> > >  819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os
> > >  ^^^^^^
> > >        2.6 still needs a hard diet... :-/
> >
> > I did the same observation a few weeks ago on 2.5.74/gcc-2.95.3. I tried
> > to track down the responsible, to the point that I completely disabled
> > every driver, networking option and file-system, just to see, and got about
> > a 550 kB vmlinux compiled with -Os. 550 kB for nothing :-(
> 
> Some of the bigger 2.6 additions cannot be configured out.
> I wish sysfs and the different I/O schedulers could be removed.
> 
> There are probably many other things mostly useless for embedded
> systems that I'm not aware of.

Well, from Pat's talk at OLS, it seems like sysfs would be an important
part of 'sleep', which is something at least some embedded systems care
about.

... not that 2.6 doesn't need some good pruning options now, but maybe
CONFIG_EMBEDDED isn't the right place to put them all.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [uClinux-dev] Kernel 2.6 size increase

[Bernardo Innocenti]

On Monday 28 July 2003 19:13, Nicolas Pitre wrote:

> > Removing the I/O schedulers is pretty trivial, please come up with a
> > patch to make both of them optional and maybe add a trivial noop one.
> >
> > Removing sysfs should also be pretty trivial but I'm not sure whether
> > you really want that.
>
> Being able to remove the block layer entirely, just as for the networking
> layer, should be considered too, since none of ramfs, tmpfs, nfs, smbfs,
> jffs and jffs2 just to name those ones actually need the block layer to
> operate.  This is really a big pile of dead code in many embedded setups.

It's a great idea.

I've read in the Kconfig help that JFFS2 still depends on mtdblock even
though it doesn't use it for I/O. I think I've also seen some promise
that this dependency will eventually be removed...

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

Re: [uClinux-dev] Kernel 2.6 size increase

[Nicolas Pitre]

On Fri, 25 Jul 2003, Christoph Hellwig wrote:

> On Thu, Jul 24, 2003 at 10:27:16PM +0200, Bernardo Innocenti wrote:
> > Some of the bigger 2.6 additions cannot be configured out.
> > I wish sysfs and the different I/O schedulers could be removed.
> 
> Removing the I/O schedulers is pretty trivial, please come up with a
> patch to make both of them optional and maybe add a trivial noop one.
> 
> Removing sysfs should also be pretty trivial but I'm not sure whether
> you really want that.

Being able to remove the block layer entirely, just as for the networking
layer, should be considered too, since none of ramfs, tmpfs, nfs, smbfs,
jffs and jffs2 just to name those ones actually need the block layer to
operate.  This is really a big pile of dead code in many embedded setups.


Nicolas

Re: [uClinux-dev] Kernel 2.6 size increase

[bill davidsen]

In article <200307242227.16439.bernie@develer.com>,
Bernardo Innocenti  <bernie@develer.com> wrote:
| On Thursday 24 July 2003 00:27, Willy Tarreau wrote:
| 
| > On Thu, Jul 24, 2003 at 12:07:15AM +0200, Bernardo Innocenti wrote:
| > >    text    data     bss     dec     hex filename
| > >  633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os
| > >  819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os
| > >  ^^^^^^
| > >        2.6 still needs a hard diet... :-/
| >
| > I did the same observation a few weeks ago on 2.5.74/gcc-2.95.3. I tried
| > to track down the responsible, to the point that I completely disabled
| > every driver, networking option and file-system, just to see, and got about
| > a 550 kB vmlinux compiled with -Os. 550 kB for nothing :-(
| 
| Some of the bigger 2.6 additions cannot be configured out.
| I wish sysfs and the different I/O schedulers could be removed.

Perhaps after 2.6.n is out and stable for a month or so someone could
look at the problem. Certainly the various io schedulers are good
candidates for being optional and/or modules. The problem is that the
parts which aren't needed aren't large, so you may not gain much.

Clearly you have to have *some* io scheduler, I'm not sure if sysfs is
optional in any meaningful way any more. I haven't tried running w/i
/proc in a few months, it didn't work when I did, but old kernels are
old news.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [uClinux-dev] Kernel 2.6 size increase

[Christoph Hellwig]

On Thu, Jul 24, 2003 at 10:27:16PM +0200, Bernardo Innocenti wrote:
> Some of the bigger 2.6 additions cannot be configured out.
> I wish sysfs and the different I/O schedulers could be removed.

Removing the I/O schedulers is pretty trivial, please come up with a
patch to make both of them optional and maybe add a trivial noop one.

Removing sysfs should also be pretty trivial but I'm not sure whether
you really want that.

Re: [uClinux-dev] Kernel 2.6 size increase

[Bernardo Innocenti]

On Thursday 24 July 2003 00:27, Willy Tarreau wrote:

> On Thu, Jul 24, 2003 at 12:07:15AM +0200, Bernardo Innocenti wrote:
> >    text    data     bss     dec     hex filename
> >  633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os
> >  819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os
> >  ^^^^^^
> >        2.6 still needs a hard diet... :-/
>
> I did the same observation a few weeks ago on 2.5.74/gcc-2.95.3. I tried
> to track down the responsible, to the point that I completely disabled
> every driver, networking option and file-system, just to see, and got about
> a 550 kB vmlinux compiled with -Os. 550 kB for nothing :-(

Some of the bigger 2.6 additions cannot be configured out.
I wish sysfs and the different I/O schedulers could be removed.

There are probably many other things mostly useless for embedded
systems that I'm not aware of.

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

Re: [uClinux-dev] Kernel 2.6 size increase

[Alan Cox]

On Mer, 2003-07-23 at 23:27, Willy Tarreau wrote:
> I was interested in using a very minimal pre-boot kernel with kexec which would
> automatically select a valid image among several ones. But 500 kB overhead for
> a boot loader quickly refrained me...

Something like the GPL'd eCos might be a better option (or on x86 there
is the 64K Linux 8086)

Re: [uClinux-dev] Kernel 2.6 size increase

[Willy Tarreau]

Hi !

On Thu, Jul 24, 2003 at 12:07:15AM +0200, Bernardo Innocenti wrote:
 
>    text    data     bss     dec     hex filename
>  633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os
>  819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os
>  ^^^^^^
>        2.6 still needs a hard diet... :-/

I did the same observation a few weeks ago on 2.5.74/gcc-2.95.3. I tried
to track down the responsible, to the point that I completely disabled every
driver, networking option and file-system, just to see, and got about a 550 kB
vmlinux compiled with -Os. 550 kB for nothing :-(

I don't have the config nor the exact numbers right here now, but I can
redo the tests on 2.6.0-test1 if needed.

I was interested in using a very minimal pre-boot kernel with kexec which would
automatically select a valid image among several ones. But 500 kB overhead for
a boot loader quickly refrained me...

Cheers,
Willy

Re: [uClinux-dev] Kernel 2.6 size increase

[Bernardo Innocenti]

On Wednesday 23 July 2003 23:57, Bernardo Innocenti wrote:

> NOTE: I just noticed the 2.4.x kernel was built with -O1 because I
> had symbolic debug enabled. That's not fair: 2.4.20 would probably
> come out even smaller than I reported!

Here come the numbers:

   text    data     bss     dec     hex filename
 640564   39152  134260  813976   c6b98 linux-2.4.x/linux-O1
 633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os


So the new comparison base is:

   text    data     bss     dec     hex filename
 633028   37952  134260  805240   c4978 linux-2.4.x/linux-Os
 819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os
 ^^^^^^
       2.6 still needs a hard diet... :-/

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

Re: [uClinux-dev] Kernel 2.6 size increase

[Bernardo Innocenti]

On Wednesday 23 July 2003 21:32, Christoph Hellwig wrote:

> Yes, we need to get this down again.  What compiler and compiler
> flags are you using?  Could you retry with the following ripped
> from include/linux/compiler.h:
>
> #if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
> #define inline          __inline__ __attribute__((always_inline))
> #define __inline__      __inline__ __attribute__((always_inline))
> #define __inline        __inline__ __attribute__((always_inline))
> #endif

Not much changed:

   text    data     bss     dec     hex filename
 845924   51204   78896  976024   ee498 linux-2.5.x/vmlinux-inline
 840368   48392   78896  967656   ec3e8 linux-2.5.x/vmlinux-noinline

By the way: this is uClinux 2.5.75-uc0. 2.6.0-test1 should be very close.
I'm building with gcc 3.3.1-pre with some ColdFire/uClinux patches.

> I'd especially be interested in the fs/ numbers after this.

 Neither did it change much here:

   text    data     bss     dec     hex filename
 224145    6952    5468  236565   39c15 linux-2.5.x/fs/built-in.o.inline
 223591    6952    5468  236011   399eb linux-2.5.x/fs/built-in.o

> Also -Os on both would be quite cool.

   text    data     bss     dec     hex filename
 845924   51204   78896  976024   ee498 linux-2.5.x/vmlinux-inline-O2
 819276   52460   78896  950632   e8168 linux-2.5.x/vmlinux-inline-Os

   text    data     bss     dec     hex filename
 840368   48392   78896  967656   ec3e8 linux-2.5.x/vmlinux-noinline-O2
 815052   48316   78896  942264   e60b8 linux-2.5.x/vmlinux-noinline-Os

This is quite a saving! I'll send a patch to Greg (uClinux maintainer)
once I've tested it a bit more.


NOTE: I just noticed the 2.4.x kernel was built with -O1 because I
had symbolic debug enabled. That's not fair: 2.4.20 would probably
come out even smaller than I reported!

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

Re: [uClinux-dev] Kernel 2.6 size increase

[Christoph Hellwig]

On Wed, Jul 23, 2003 at 01:22:56PM -0700, David S. Miller wrote:
> Drivers weren't audited much, and there's a lot of boneheaded
> stuff in this area.  But these should be mostly identical
> to what would happen on the 2.4.x side

Please read the original message again - he stated that every single
module in fs/ got alot bigger - if it gets smaller or at least the
same size as 2.4 it's clearly a sign of inlines gone mad in the
filesystem/VM code and we need to look at that.  If not we have to look
elsewhere.

Re: [uClinux-dev] Kernel 2.6 size increase

[David S. Miller]

On Wed, 23 Jul 2003 21:15:33 +0100
Christoph Hellwig <hch@infradead.org> wrote:

> I just wanted to see whether gcc actually is smarter than us
> so we need to remove some more inlines..

Drivers weren't audited much, and there's a lot of boneheaded
stuff in this area.  But these should be mostly identical
to what would happen on the 2.4.x side

Re: [uClinux-dev] Kernel 2.6 size increase

[Christoph Hellwig]

On Wed, Jul 23, 2003 at 01:11:54PM -0700, David S. Miller wrote:
> Careful, some platforms won't work with this.

I didn't say I want this changed again in mainline, I just
wanted to see whether gcc actually is smarter than us so we
need to remove some more inlines..

Re: [uClinux-dev] Kernel 2.6 size increase

[David S. Miller]

On Wed, 23 Jul 2003 21:32:46 +0200
Christoph Hellwig <hch@lst.de> wrote:

> Could you retry with the following ripped
> from include/linux/compiler.h:
> 
> #if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
> #define inline          __inline__ __attribute__((always_inline))
> #define __inline__      __inline__ __attribute__((always_inline))
> #define __inline        __inline__ __attribute__((always_inline))
> #endif

Careful, some platforms won't work with this.

I know that ppc64's switch_to() for example must be inlined or else
the kernel stops working.  It's either the above defines or adding
-finline-limit=100000 to the GCC command line to force it to be
inlined.

Re: [uClinux-dev] Kernel 2.6 size increase

[Christoph Hellwig]

On Wed, Jul 23, 2003 at 08:46:46PM +0200, 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
> 
> 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.

Yes, we need to get this down again.  What compiler and compiler
flags are you using?  Could you retry with the following ripped
from include/linux/compiler.h:

#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
#define inline          __inline__ __attribute__((always_inline))
#define __inline__      __inline__ __attribute__((always_inline))
#define __inline        __inline__ __attribute__((always_inline))
#endif

I'd especially be interested in the fs/ numbers after this.

Also -Os on both would be quite cool.