Re: Kernel 2.6 size increase

Re: Kernel 2.6 size increase

[Ihar "Philips" Filipau]

Tom Rini wrote:
> 
> Power Management, sysfs plays / will play a role in finding out the order
> in which devices get powered down.  This is important on some types of
> embedded devices (and arguably important everywhere).
> 

   You are contradicting to yourself.

   I have participated in creation of two specialized embedded systems, 
and currently going into third one.
   Every system were need some specialized shutdown sequence.
   None of them were need power saving.

   Please do not generalize your particular system to everything else.

   No one needs another self-aware self-configurable software subsystem, 
which intended to do the task of the engineers. Especially when this 
task takes 15 minutes to code.

Re: Kernel 2.6 size increase

[Tom Rini]

On Thu, Jul 31, 2003 at 06:31:29PM +0200, Ihar Philips Filipau wrote:
> Tom Rini wrote:
> >
> >Power Management, sysfs plays / will play a role in finding out the order
> >in which devices get powered down.  This is important on some types of
> >embedded devices (and arguably important everywhere).
> >
> 
>   You are contradicting to yourself.
> 
>   I have participated in creation of two specialized embedded systems, 
> and currently going into third one.
>   Every system were need some specialized shutdown sequence.
>   None of them were need power saving.

Shutdown != sleep.  If you want to wake devices up again, you need to do
them in the right order.

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

Re: Kernel 2.6 size increase

[Ihar "Philips" Filipau]

Tom Rini wrote:
> 
> Shutdown != sleep.  If you want to wake devices up again, you need to do
> them in the right order.
> 

     You didn't get my point.
     My appliances do not need sleep/shutdown at all.
     Not every embedded system is a handheld ;-)

     Shutdown was smth like:
     # mount / -o ro; sync; lcd-off; \
	dd if=/dev/zero seek=0xBYE of=/dev/port
     For a long time it was shell script :-)))

Re: Kernel 2.6 size increase

[Tom Rini]

On Thu, Jul 31, 2003 at 07:04:49PM +0200, Ihar Philips Filipau wrote:
> Tom Rini wrote:
> >
> >Shutdown != sleep.  If you want to wake devices up again, you need to do
> >them in the right order.
> 
>     You didn't get my point.
>     My appliances do not need sleep/shutdown at all.
>     Not every embedded system is a handheld ;-)

That certainly is true, yes.  They might want to power things down when
the user isn't there (or maybe they don't, I don't know what you're
making :)).  And I did originally say 'some'.

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

Re: Kernel 2.6 size increase

[Ihar "Philips" Filipau]

Tom Rini wrote:
>>
>>    You didn't get my point.
>>    My appliances do not need sleep/shutdown at all.
>>    Not every embedded system is a handheld ;-)
> 
> 
> That certainly is true, yes.  They might want to power things down when
> the user isn't there (or maybe they don't, I don't know what you're
> making :)).  And I did originally say 'some'.
> 

   Can you imagine teapot?
   State of your system - on/off. Power saving as done by user herself: 
power is consumed only when user want to boil the water ;-)

   Two devices I was working on were little bit more complicated and I 
had internal UPS to be able to handle power offs/fails gracefuly (like 
switching off of LCD + save of the mechanics state).

   As for me - I already expressed my point on subject: we should fix 
compiler and language (C's inline is definitely not ehough to express 
our intentions to compiler). That's the compiler should be optimized to 
gain space for performace or gain performance for space.

   And sure kernel should be more configurable too.

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

[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: Kernel 2.6 size increase

[Miles Bader]

Bernardo Innocenti <bernie@develer.com> writes:
> > 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.

Yup.

When I've used a debugger to trace through the kernel reading a block on
a system using only romfs, it's utterly amazing how much completely
unnecessary stuff happens.

Of course it's a lot harder to find a clean way to make it optional
than it is to complain about it ... :-)

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Kernel 2.6 size increase

[Bernardo Innocenti]

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

Re: Kernel 2.6 size increase

[Richard B. Johnson]

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.

Re: Kernel 2.6 size increase

[David S. Miller]

On Wed, 23 Jul 2003 15:14:22 -0400 (EDT)
"Richard B. Johnson" <root@chaos.analogic.com> wrote:

> On Wed, 23 Jul 2003, Bernardo Innocenti wrote:
> 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.

GCC 3.3 and later do this automatically.

It's weird, since we killed TONS of explicit zero initializers during
2.5.x, you'd be pressed to find many examples like the one you
mention.

Another thing is that the define_per_cpu() stuff eliminated many huge
[NR_CPUS] arrays.  But this probably doesn't apply to his kernel
unless he built is with SMP enabled.

Re: Kernel 2.6 size increase

[Randy.Dunlap]

On Wed, 23 Jul 2003 13:07:12 -0700 "David S. Miller" <davem@redhat.com> wrote:

| On Wed, 23 Jul 2003 15:14:22 -0400 (EDT)
| "Richard B. Johnson" <root@chaos.analogic.com> wrote:
| 
| > On Wed, 23 Jul 2003, Bernardo Innocenti wrote:
| > 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.
| 
| GCC 3.3 and later do this automatically.
| 
| It's weird, since we killed TONS of explicit zero initializers during
| 2.5.x, you'd be pressed to find many examples like the one you
| mention.
| 
| Another thing is that the define_per_cpu() stuff eliminated many huge
| [NR_CPUS] arrays.  But this probably doesn't apply to his kernel
| unless he built is with SMP enabled.

Yes, lots were already killed off, but there are also several
kernel-janitor patches to remove many more static 0 inits.
They can be found at
  http://developer.osdl.org/ogasawara/kj-patches/uninit_static/
and I'll be trying to have them merged, although I don't know
how well they will be accepted.

--
~Randy

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

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

[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

[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 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: Kernel 2.6 size increase

[Miles Bader]

Tom Rini <trini@kernel.crashing.org> writes:
> 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 ?

Sure, but not nice enough to justify requiring more memory or whatever
(of course just that one feature's not going to make much difference,
but in aggregate, they might).

-Miles
-- 
Run away!  Run away!

Re: Kernel 2.6 size increase

[Tom Rini]

On Wed, Jul 30, 2003 at 11:07:24AM +0900, Miles Bader wrote:
> Tom Rini <trini@kernel.crashing.org> writes:
> > 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 ?
> 
> Sure, but not nice enough to justify requiring more memory or whatever
> (of course just that one feature's not going to make much difference,
> but in aggregate, they might).

Well, that sort-of depends on which 'embedded' board you're talking
about really.  And the trade-off between the work needed for a hacked-up
1 off, the space that could be saved by doing this, and the space that
could be saved elsewhere.  Perhaps on the embedded_in_my_fridge machine
it might make sense, but not ever embedded device is quite so tiny and
strapped for space.

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

Re: Kernel 2.6 size increase

[Miles Bader]

Tom Rini <trini@kernel.crashing.org> writes:
> > but not nice enough to justify requiring more memory or whatever (of
> > course just that one feature's not going to make much difference,
> > but in aggregate, they might).
> 
> Well, that sort-of depends on which 'embedded' board you're talking
> about really.

The point was that in _some_ embedded systems, the space-savings is
wanted, and so a useful thing for linux to support.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Kernel 2.6 size increase

[Tom Rini]

On Thu, Jul 31, 2003 at 10:49:06AM +0900, Miles Bader wrote:
> Tom Rini <trini@kernel.crashing.org> writes:
> > > but not nice enough to justify requiring more memory or whatever (of
> > > course just that one feature's not going to make much difference,
> > > but in aggregate, they might).
> > 
> > Well, that sort-of depends on which 'embedded' board you're talking
> > about really.
> 
> The point was that in _some_ embedded systems, the space-savings is
> wanted, and so a useful thing for linux to support.

To what end?  One of the things we (== PPC folks) at OLS was that, wow,
doing PM as some sort of one-off sucks, and if at all possible we want
to get device information (and pm dependancies) passed in so we can tell
sysfs and get any shared driver done right for free, among other
reasons.

As has been pointed out, there's things like the block layer that aren't
needed if you have just a subset of common embedded-device filesystems and
some network stuff seems to have creeped back in.  All I'm trying to say
is that before you go too far down the CONFIG_SYSFS route, investigate the
others first as there's a fair chance of saving even more.

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

Re: Kernel 2.6 size increase

[Miles Bader]

Tom Rini <trini@kernel.crashing.org> writes:
> > The point was that in _some_ embedded systems, the space-savings is
> > wanted, and so a useful thing for linux to support.
> 
> As has been pointed out, there's things like the block layer that aren't
> needed if you have just a subset of common embedded-device filesystems and
> some network stuff seems to have creeped back in.  All I'm trying to say
> is that before you go too far down the CONFIG_SYSFS route, investigate the
> others first as there's a fair chance of saving even more.

I'm not really trying to defend this particular config option, just
saying that the attitude of `why bother trying to cut down, it's more
featureful to include everything!' is not always valid.

You may very well be right that other subsystems offer better
gain/pain, and I'm all for attacking the low-hanging-fruit first.

> To what end?  One of the things we (== PPC folks) at OLS was that, wow,
> doing PM as some sort of one-off sucks, and if at all possible we want
> to get device information (and pm dependancies) passed in so we can tell
> sysfs and get any shared driver done right for free, among other
> reasons.

[What's PM?  Power Management?  What does that have to do with anything?]

-Miles
-- 
Would you like fries with that?

Re: Kernel 2.6 size increase

[Tom Rini]

On Thu, Jul 31, 2003 at 02:03:34PM +0900, Miles Bader wrote:
> Tom Rini <trini@kernel.crashing.org> writes:
> > > The point was that in _some_ embedded systems, the space-savings is
> > > wanted, and so a useful thing for linux to support.
> > 
> > As has been pointed out, there's things like the block layer that aren't
> > needed if you have just a subset of common embedded-device filesystems and
> > some network stuff seems to have creeped back in.  All I'm trying to say
> > is that before you go too far down the CONFIG_SYSFS route, investigate the
> > others first as there's a fair chance of saving even more.
> 
> I'm not really trying to defend this particular config option, just
> saying that the attitude of `why bother trying to cut down, it's more
> featureful to include everything!' is not always valid.

I hate email sometimes.  My attitude is "some things you really can't
cut out".  I really am all for trying to cut things out, it's just that
some things are tied in rather well (like sysfs and root device as
opposed to the static table before).

> You may very well be right that other subsystems offer better
> gain/pain, and I'm all for attacking the low-hanging-fruit first.
> 
> > To what end?  One of the things we (== PPC folks) at OLS was that, wow,
> > doing PM as some sort of one-off sucks, and if at all possible we want
> > to get device information (and pm dependancies) passed in so we can tell
> > sysfs and get any shared driver done right for free, among other
> > reasons.
> 
> [What's PM?  Power Management?  What does that have to do with anything?]

Power Management, sysfs plays / will play a role in finding out the order
in which devices get powered down.  This is important on some types of
embedded devices (and arguably important everywhere).

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