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

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

[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

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

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

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