Unbloating the kernel, was: :mem=16MB laptop testing

Unbloating the kernel, was: :mem=16MB laptop testing

[Marco Fioretti]

> So I tried mem=16m on my laptop (stinkpad T21). I made the following
> potentially useless observations:
[snip]
> I guess the upshot is "unbloating" the kernel wouldn't do much good
> anyway, since luserspace isn't in any kind of shape to run in this kind
> of environment anymore either.

Wrong. (please read till the end, this is not academic, but a real call to arms!)

Have a look at http://www.rule-project.org/en/, specifically the pages:

http://www.rule-project.org/en/sw/kdrive.php (how we do without X, solving half
of the problem)

http://www.rule-project.org/en/test/                 (the kind of machines we
must work with)

There are still a *lot* of lightweight applications giving real functionality
without bloat.
Of course, they can make little in these conditions if constantly swapped out from
the Kernel and/or X.

With 16 or 24 MB or RAM even half a meg less is very important. We at RULE are
doing what we can to select light GUI applications and test them with kdrive,
but have
no expertise to look after the kernel.

Any help whatsoever in keeping 2.6 as light as possible, and to recompile stock
2.4 kernels
to lighten them is really needed.

The most important part of this is that it is not a programming contest, just
for the sake of it.

There are literally thousands of schools, all over the world, which simply
cannot afford
any money on computers. The "HW is cheap" slogan is very cruel when recited in
places
where 64 MB of RAM are one month's salary. I am not kidding. All these schools
have is
donated computers 5+ years old: even if they had the money they could not find
spare parts
from them.

After food, medicines and shelter a good education is essential to make a decent
living.

It is extremely embarassing to tell these students "you can do without expensive
MS SW,
just find the money for a PC almost as expensive as those which will run Windows".

A lightweight Linux is needed to many more people than the full featured one

Thank you in advance for any support,

             Marco Fioretti, RULE project coordinator

PS: Oh, and while I'm at it, I'll even dare to ask for RULE network volunteers, see
http://www.rule-project.org/en/rule_by_email.php

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[William Lee Irwin III]

At some point in the past, I wrote:
>> So I tried mem=16m on my laptop (stinkpad T21). I made the following
>> potentially useless observations:
[snip]
>> I guess the upshot is "unbloating" the kernel wouldn't do much good
>> anyway, since luserspace isn't in any kind of shape to run in this kind
>> of environment anymore either.

On Tue, Oct 14, 2003 at 01:44:31PM +0200, Marco Fioretti wrote:
> Wrong. (please read till the end, this is not academic, but a real
> call to arms!) Have a look at http://www.rule-project.org/en/,
> specifically the pages: http://www.rule-project.org/en/sw/kdrive.php
> (how we do without X, solving half of the problem)

Hearing this is about the happiest I can be to be proven wrong.


On Tue, Oct 14, 2003 at 01:44:31PM +0200, Marco Fioretti wrote:
> http://www.rule-project.org/en/test/ (the kind of machines we must
> work with) There are still a *lot* of lightweight applications giving
> real functionality without bloat. Of course, they can make little in
> these conditions if constantly swapped out from > the Kernel and/or X.
> With 16 or 24 MB or RAM even half a meg less is very important. We at
> RULE are doing what we can to select light GUI applications and test
> them with kdrive, but have no expertise to look after the kernel.
> Any help whatsoever in keeping 2.6 as light as possible, and to
> recompile stock 2.4 kernels to lighten them is really needed.
> The most important part of this is that it is not a programming
> contest, just for the sake of it.
> There are literally thousands of schools, all over the world, which simply
> cannot afford any money on computers. The "HW is cheap" slogan is
> very cruel when recited in places where 64 MB of RAM are one month's
> salary. I am not kidding. All these schools have is donated computers
> 5+ years old: even if they had the money they could not find spare parts
> from them. After food, medicines and shelter a good education is
> essential to make a decent living.
> It is extremely embarassing to tell these students "you can do
> without expensive MS SW, just find the money for a PC almost as
> expensive as those which will run Windows". A lightweight Linux is
> needed to many more people than the full featured one Thank you in
> advance for any support,
>              Marco Fioretti, RULE project coordinator
> PS: Oh, and while I'm at it, I'll even dare to ask for RULE network volunteers, see
> http://www.rule-project.org/en/rule_by_email.php

"$FOO is cheap" is a copout for sure; in the wrong country or for the
wrong people the limitation to "performant" hardware is a lethal blow
to usability. I'm not sure how to say how glad I am to hear of a direct
attack on this issue.

If you and/or your cohorts could inform us of kernel usability issues,
especially with 2.6, I would be much obliged (all the more so for a cc:).


-- wli

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Rik van Riel]

On Tue, 14 Oct 2003, Marco Fioretti wrote:

> There are literally thousands of schools, all over the world, which
> simply cannot afford any money on computers. The "HW is cheap" slogan is
> very cruel when recited in places where 64 MB of RAM are one month's
> salary. I am not kidding.

I am very happy to see that there is a project to take
care of the needs of people with older hardware.

If you ever need help on the kernel side, let me know.

I know a lot of friends in various countries who simply
don't have the money to buy a new computer. Granted, 64MB
isn't anywhere near a monthly salary for most of them,
but after paying their bills they still don't have enough
money left to buy a new computer (and if they had, they
should buy something else with it ... there really isn't
a good excuse on why software is getting this much more
bloated).

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[jlnance]

On Tue, Oct 14, 2003 at 09:24:17AM -0400, Rik van Riel wrote:
> On Tue, 14 Oct 2003, Marco Fioretti wrote:
> 
> > There are literally thousands of schools, all over the world, which
> > simply cannot afford any money on computers. The "HW is cheap" slogan is
> > very cruel when recited in places where 64 MB of RAM are one month's
> > salary. I am not kidding.

Let me concur with the sentiments on this thread.

When I started using Linux, it was on a 40 MHz 386 with 8Megs of ram and
a 200 Meg HD.  This was a reasonably typical machine for the time (1993).
I ran X on this machine, and it was fine running several Xterms and you
could play the X version of Tetris or gnuchess.  I used this machine to
write the program I was working on for my Masters degree.

Today, a machine with specs like I quoted above seems hopelessly slow.
However, I was able to do useful work on it in 1993, and the same sort
of work would still be useful today.  You of course are not going to be
able to run mozilla and KDE on it, but lynx, slrn, mutt, and fvwm will
work fine.  There are many people who will never be able to afford
to buy a computer but could find someone to give them one of these
"hopelessy outdated" machines for nothing.  If we can ensure that
Linux keeps working on these machines, it will be a good thing.

Thanks,

Jim

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Richard B. Johnson]

On Tue, 14 Oct 2003 jlnance@unity.ncsu.edu wrote:

> On Tue, Oct 14, 2003 at 09:24:17AM -0400, Rik van Riel wrote:
> > On Tue, 14 Oct 2003, Marco Fioretti wrote:
> >
> > > There are literally thousands of schools, all over the world, which
> > > simply cannot afford any money on computers. The "HW is cheap" slogan is
> > > very cruel when recited in places where 64 MB of RAM are one month's
> > > salary. I am not kidding.
>
> Let me concur with the sentiments on this thread.
>
> When I started using Linux, it was on a 40 MHz 386 with 8Megs of ram and
> a 200 Meg HD.  This was a reasonably typical machine for the time (1993).
> I ran X on this machine, and it was fine running several Xterms and you
> could play the X version of Tetris or gnuchess.  I used this machine to
> write the program I was working on for my Masters degree.

Information:

Booting Linux-2.4.22 with mem=16M, I can still compile the
kernel as `make -j 16 bzImage` with the following resources:


        total:    used:    free:  shared: buffers:  cached:
Mem:  14544896 14118912   425984        0   274432  6713344
Swap: 1069268992 16510976 1052758016
MemTotal:        14204 kB
MemFree:           416 kB
MemShared:           0 kB
Buffers:           268 kB
Cached:           3264 kB
SwapCached:       3320 kB
Active:           5980 kB
Inactive:         2944 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        14204 kB
LowFree:           388 kB
SwapTotal:     1044208 kB
SwapFree:      1028084 kB

After a `make clean`, this configuration normally takes
about 3 minutes to compile. With mem=16M, it takes about
12 minutes. Not too bad.

The kernel is as 'modular' as one can make it. I don't have
any built-in stuff that I don't use. This helps keep it
small. But...it is growing in size for no obvious gain.
-rwxr-xr-x   1 root     root      1532520 Mar 13  2003 vmlinux
                                  ^^^^^^^___ linux-2.4.20
-rwxr-xr-x   1 root     root      1567340 Oct 14 09:39 vmlinux
                                  ^^^^^^^___ linux-2.4.22
Both of these kernels have the exact configuration and are
built with the exact same tools.

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

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Maciej Zenczykowski]

> Let me concur with the sentiments on this thread.
> 
> When I started using Linux, it was on a 40 MHz 386 with 8Megs of ram and
> a 200 Meg HD.  This was a reasonably typical machine for the time (1993).
> I ran X on this machine, and it was fine running several Xterms and you
> could play the X version of Tetris or gnuchess.  I used this machine to
> write the program I was working on for my Masters degree.
> 
> Today, a machine with specs like I quoted above seems hopelessly slow.
> However, I was able to do useful work on it in 1993, and the same sort
> of work would still be useful today.  You of course are not going to be
> able to run mozilla and KDE on it, but lynx, slrn, mutt, and fvwm will
> work fine.  There are many people who will never be able to afford
> to buy a computer but could find someone to give them one of these
> "hopelessy outdated" machines for nothing.  If we can ensure that
> Linux keeps working on these machines, it will be a good thing.

On one hand I agree with you - OTOH: why not run an older version of the
kernel? Are kernel versions 2.2 or even 2.0 really not sufficient for such
a situation?  It should be noted that newer kernels are adding a whole lot
of drivers which aren't much use with old hardware anyway and only a
little actual non-driver related stuff (sure it's an oversimplification,
but...).  Just like you don't expect to run the latest
games/X/mozilla/kde/gnome on old hardware perhaps you shouldn't run the
latest kernel... perhaps you should...

Sure I would really like to be able to compile a 2.6 for my 
firewall (486DX33+40MB-2MB badram) - but is this the way to go?

As for making the kernel smaller - perhaps a solution would be to code all 
strings as error codes and return ERROR#42345 or something instead of the 
full messages - there seem to be quite a lot of them.  I don't mean to 
suggest this solution for all compilations but perhaps a switch to remove 
strings and replace them with ints and then a seperately generated file of 
errnum->string. I'd expect that between 10-15% of the uncompressed kernel 
is currently pure text.

Perhaps int->string conversion could be done by a loadable module or a 
userspace program?

Just my 3c and some ideas.

Of course part of the problem is that by designing the kernel for high mem 
situations we're using more memory hogging algorithms.  It's a simple 
matter of features vs mem footprint.

I'm not convinced either way - and I'm just posting this 
as a voice in this discussion...

Cheers,
MaZe.

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[John Bradford]

> On one hand I agree with you - OTOH: why not run an older version of the
> kernel?

Security issues.  That applies for userspace as well.  Not upgrading,
or at least disabling the functionality with the security issue is
irresponsible.

Actually, this is one thing we could do to make Linux systems more
usable on low spec hardware - fix all the security issues in ancient
versions of the kernel and popular userspace applications.

> Are kernel versions 2.2 or even 2.0 really not sufficient for such
> a situation?  It should be noted that newer kernels are adding a whole lot
> of drivers which aren't much use with old hardware anyway and only a
> little actual non-driver related stuff (sure it's an oversimplification,
> but...).  Just like you don't expect to run the latest
> games/X/mozilla/kde/gnome on old hardware perhaps you shouldn't run the
> latest kernel... perhaps you should...

No, 2.6 should run on a 4MB 386 with no significant performance
penalty against 2.0, in my opinion.

> Sure I would really like to be able to compile a 2.6 for my 
> firewall (486DX33+40MB-2MB badram) - but is this the way to go?

Why not?

> As for making the kernel smaller - perhaps a solution would be to code all 
> strings as error codes and return ERROR#42345 or something instead of the 
> full messages - there seem to be quite a lot of them.  I don't mean to 
> suggest this solution for all compilations but perhaps a switch to remove 
> strings and replace them with ints and then a seperately generated file of 
> errnum->string. I'd expect that between 10-15% of the uncompressed kernel 
> is currently pure text.

I agree, error codes would be nice, but this discussion has come up
before and I doubt they will ever get in to mainline.

> Perhaps int->string conversion could be done by a loadable module or a 
> userspace program?

Not really going to help much, in my opinion, it'll just add overhead.

John.

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Richard B. Johnson]

On Tue, 14 Oct 2003, John Bradford wrote:

> > On one hand I agree with you - OTOH: why not run an older version of the
> > kernel?
>
> Security issues.  That applies for userspace as well.  Not upgrading,
> or at least disabling the functionality with the security issue is
> irresponsible.
[SNIPPED...]


>
> > As for making the kernel smaller - perhaps a solution would be to code all
> > strings as error codes and return ERROR#42345 or something instead of the
> > full messages - there seem to be quite a lot of them.  I don't mean to
> > suggest this solution for all compilations but perhaps a switch to remove
> > strings and replace them with ints and then a seperately generated file of
> > errnum->string. I'd expect that between 10-15% of the uncompressed kernel
> > is currently pure text.
>
> I agree, error codes would be nice, but this discussion has come up
> before and I doubt they will ever get in to mainline.
>

Really good guess!

-rw-r--r--   1 root     root       151483 Oct 14 13:49 Strings.txt
-rwxr-xr-x   1 root     root      1567340 Oct 14 09:39 vmlinux

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

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[tabris]

On Tuesday 14 October 2003 12:27 pm, Maciej Zenczykowski wrote:
> > Let me concur with the sentiments on this thread.
> >
> > When I started using Linux, it was on a 40 MHz 386 with 8Megs of ram
> > and a 200 Meg HD.  This was a reasonably typical machine for the time
> > (1993). I ran X on this machine, and it was fine running several
> > Xterms and you could play the X version of Tetris or gnuchess.  I
> > used this machine to write the program I was working on for my
> > Masters degree.
> >
> > Today, a machine with specs like I quoted above seems hopelessly
> > slow. However, I was able to do useful work on it in 1993, and the
> > same sort of work would still be useful today.  You of course are not
> > going to be able to run mozilla and KDE on it, but lynx, slrn, mutt,
> > and fvwm will work fine.  There are many people who will never be
> > able to afford to buy a computer but could find someone to give them
> > one of these "hopelessy outdated" machines for nothing.  If we can
> > ensure that Linux keeps working on these machines, it will be a good
> > thing.
>
> On one hand I agree with you - OTOH: why not run an older version of
> the kernel? Are kernel versions 2.2 or even 2.0 really not sufficient
> for such a situation?  It should be noted that newer kernels are adding
> a whole lot of drivers which aren't much use with old hardware anyway
> and only a little actual non-driver related stuff (sure it's an
> oversimplification, but...).  Just like you don't expect to run the
> latest
> games/X/mozilla/kde/gnome on old hardware perhaps you shouldn't run the
> latest kernel... perhaps you should...
>
> Sure I would really like to be able to compile a 2.6 for my
> firewall (486DX33+40MB-2MB badram) - but is this the way to go?
>
Well... So far, 2.4 is enough for my routers. BUT, I also cannot put more 
than 32-40MB into them (i just don't have the budget to go buy 16MB FP or 
EDO DIMMs when I already have a bunch of 8MB DIMMs.

I started my project running 2.2, but that wasn't enough for what I 
needed. It might have been fine for the most part, but iproute2 doesn't 
work completely on 2.2, and there's no IPTABLES. sure, ipchains is 
simpler to config by hand, but I still want to use iptables when I can 
for the increased flexibility.

Simple fact. not everything can, or will, be backported. And not everybody 
can just make their own raw distribution. (tho it might have helped if i 
had used debian instead of RedHat on my router). and many modern distro 
installers don't like 32MB RAM... that's what i ran into.


> As for making the kernel smaller - perhaps a solution would be to code
> all strings as error codes and return ERROR#42345 or something instead
> of the full messages - there seem to be quite a lot of them.  I don't
> mean to suggest this solution for all compilations but perhaps a switch
> to remove strings and replace them with ints and then a seperately
> generated file of errnum->string. I'd expect that between 10-15% of the
> uncompressed kernel is currently pure text.
>

Considered already. Was tied into i18n. was considered impractical, esp 
w/o a realtime LANANA services or equiv for error numbers.

> Perhaps int->string conversion could be done by a loadable module or a
> userspace program?
>
> Just my 3c and some ideas.
>
> Of course part of the problem is that by designing the kernel for high
> mem situations we're using more memory hogging algorithms.  It's a
> simple matter of features vs mem footprint.
>
> I'm not convinced either way - and I'm just posting this
> as a voice in this discussion...
>
> Cheers,
> MaZe.
>
--
tabris
-
Coward, n.:
	One who in a perilous emergency thinks with his legs.
		-- Ambrose Bierce, "The Devil's Dictionary"

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Roger Larsson]

On Tuesday 14 October 2003 18.27, Maciej Zenczykowski wrote:
> Of course part of the problem is that by designing the kernel for high mem
> situations we're using more memory hogging algorithms.  It's a simple
> matter of features vs mem footprint.

Algorithms using lots of memory should be avoided even for newer computers.
Cache misses HURTS.

That is why -Os can be a better compilation option than -O2 !

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

Unbloating the kernel, action list

[M. Fioretti]

Hello,

first of all, thanks to all who answered, both on this list and
privately, with congratulations for the RULE project and the
acknowledgement that this is a serious problem.

Many of the answers also asked how to help RULE at the kernel level.
The rest of this message gives a very short background, freely mixing
some replies, and then explains what could be done. Thanks in advance
for reading it all, it is not so long. Any feedback is welcome!

	    Marco Fioretti

############################################################
BACKGROUND:

> ...not everybody can just make their own raw distribution.. and many
> modern distro installers don't like 32MB RAM...

Absolutely! Red Hat got to the point that the installer requirements
became higher than the kernel ones, which is as ugly as can be. We
solved that problem: our installer works in 12 MB. AND it installs
standard stuff from the official Cdroms of the latest stable Red Hat
(soon Fedora). Minimum effort, greatest result: after installation one
goes for support, updates, patches... to the usual Red Hat places, no
more burden for RULE.

> OTOH: why not run an older version of the kernel? Are kernel versions
> 2.2 or even 2.0 really not sufficient for such a situation?

As already mentioned, this is wrong, functionally and security wise.
See the RULE FAQ for details.

> fix all the security issues in ancient versions of the kernel and
> popular userspace applications

See above. That would be a huge effort to still remain without
iptables, Imap, digital signatures, fontconfig, Cups based
printing....

IMPORTANT: the distribution just doesn't matter. We are doing Red Hat
for a whole bunch of purely practical reasons, not for some religious
preference. On older hardware vanilla kernels, X, Gnome, Kde,
Mozilla... are just too much, regardless of the CDs they came from.

############################################################

WHAT TO DO:

Bloat must be fought in four places: installers, userland, X and
kernel. We are already dealing with the first three: apart from the
installer, things like repackaging Abiword to not require Gnome, and
kdrive. Quite honestly, we don't really have the skills and experience
to delve deeply into Linux proper, and here is how you kernel folks
can help:

1) Raise and keep alive the awareness, here and in any other place you
   can, that bloat is a serious practical problem for many people,
   schools, NGOs, etc...Any time you can. Really

2) Prepare, after discussing here, and keep updated, the most complete
   list of tricks you can think of to make the kernel and the rest of
   the system (more on this later) run faster and with less resources.
   Think to the PC you had 6/7 years ago, and work for that. Go to the
   RULE test page, and looks at the PC entries. Everything from
   compilation options to /proc or filesystem settings is useful.

   RULE can and will host happily such a page, but maybe it would be
   better to place it on kernel.org, as it should benefit all Linux
   users.

3) Which kernel and which system? The whole point of RULE is to do the
   job with current mainstream stuff. No point in cornering
   unexperienced users with something nobody else uses. Basically
   everything that would be like making a new distribution
   (nonstandard gcc, glibc, recompiling all userland for it...) is
   interesting, but not useful for us.

4) For us RULE folks, point 3) means that today we really need the
   support of point 2) on the latest official Red Hat 9 kernel, and
   starting from their source RPMs. Things like "once you have it,
   patch the spec file so and so, recompile, then once installed set
   up this and that system parameter". Repeat ad libitum whenever a
   new stable Fedora is released.

5) Again, the distro is not the issue. Once a lean kernel, Kdrive, and
   the right apps are well known, they can go everywhere. Let's work
   at THAT level first. In the meantime, if somebody really feels like
   doing the RULE thing on Debian, Mandrake, Slackware,
   whatever... call me offline and volunteer to maintain the "RULE for
   XYZ" subproject. You'll be welcome.
   More useful, but harder, would be non x86 architectures, people
   keep asking me to resurrect their Sparcs or Macs.

6) subscribe to the RULE mailing list: it is just a tiny fraction of
   the traffic on Linux-Kernel: you won't even notice it, and be there
   when somebody needs help.

7) Do come in suggesting anything I might have forgotten

-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

Go ahead, capitalize the T on technology, deify it if it will make you
feel less responsible -- but it puts you in with the neutered,
brother, in with the eunuchs keeping the harem of our stolen Earth for
the numb and joyless hardons of human sultans, human elite with no
right at all to be where they are --
			       Thomas Pynchon, _Gravity's Rainbow_

Re: Unbloating the kernel, action list

[Martin J. Bligh]

> 7) Do come in suggesting anything I might have forgotten

If you do automated testing of nightly builds of the mainline 2.6 / 2.7
kernels, and point out when they get bigger in consumption, you'll have
a much better chance of convincing people to fix it when the patch in
question is still topical, and fresh in people's minds.

I'd predict that a lot of the issue is just tuning things dynamically 
instead of statically sizing them.

M.

Re: Unbloating the kernel, action list

[cliff white]

On Tue, 14 Oct 2003 15:30:41 -0700
"Martin J. Bligh" <mbligh@aracnet.com> wrote:

> 
> > 7) Do come in suggesting anything I might have forgotten
> 
> If you do automated testing of nightly builds of the mainline 2.6 / 2.7
> kernels, and point out when they get bigger in consumption, you'll have
> a much better chance of convincing people to fix it when the patch in
> question is still topical, and fresh in people's minds.
> 
> I'd predict that a lot of the issue is just tuning things dynamically 
> instead of statically sizing them.

We (OSDL + others) are working on a continuous build/test system, using the Mozilla tinderbox.
Should be available RSN. Tinderbox supports multiple clients, and we'll
have a client package available for download. 

Marco, if you could supply time on a small client box, and a desired .config,
we can add you as a Tinderbox client,
 then you have a place to point people when the size increases. 

Either way, please send me your desired .config - i can and should 
build a size test into the tinderclient code. 

cliffw

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

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Sandy Harris]

jlnance@unity.ncsu.edu wrote:

> Let me concur with the sentiments on this thread.

Me too.

> ...  There are many people who will never be able to afford
> to buy a computer but could find someone to give them one of these
> "hopelessy outdated" machines for nothing.

Some people may be able to get more than one. A year or two
back a peniless friend of mine built quite a nice environment
for himself with two 486 boxes and a pile of SPARC IIs.

Also, there are server applications that don't need much. For
example, a firewall and NAT box for an ADSL line, or a print
spooler or ...

You could even build a Beowulf out of such machines
http://stonesoup.esd.ornl.gov/

> If we can ensure that
> Linux keeps working on these machines, it will be a good thing.

Indeed.

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Tue, 2003-10-14 18:27:05 +0200, Maciej Zenczykowski <maze@cela.pl>
wrote in message <Pine.LNX.4.44.0310141813320.1776-100000@gaia.cela.pl>:

> errnum->string. I'd expect that between 10-15% of the uncompressed kernel 
> is currently pure text.

Right. For a real lowmem system (4MB RAM) I defined printk to a no-op
and gained 90K at the compressed image IIRC. This was 2.2.x, though.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On Tue, 2003-10-14 18:33:49 +0100, John Bradford <john@grabjohn.com>
wrote in message <200310141733.h9EHXnYg002262@81-2-122-30.bradfords.org.uk>:
> No, 2.6 should run on a 4MB 386 with no significant performance
> penalty against 2.0, in my opinion.

Achtually, with HZ at around 100 (or oven 70..80), an old i386 or i486
will *start* just fine, at least at 8MB. However, over some days /
weeks, the machine gets slower and slower (my testdrive: my 90MHz
P-Classic with 16MB). Even with that "much" RAM, I get hit by whatever
slows down the machine. I *think* that it's the MM subsystem, but I'm
really not skilled enough with it to blame it:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, action list

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
wrote in message <20031014155638.7db76874.cliffw@osdl.org>:
> On Tue, 14 Oct 2003 15:30:41 -0700
> "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> > > 7) Do come in suggesting anything I might have forgotten

> Marco, if you could supply time on a small client box, and a desired .config,
> we can add you as a Tinderbox client,
>  then you have a place to point people when the size increases. 

I can put on the table:

486SLC, 12MB RAM
i386, 8MB RAM (hey, this box is nearly build up by discrete parts:)
Am386, 8MB RAM
P-Classic, 32MB RAM (even that much RAM can go short after an uptme of
about a month...)

Unfortunately, you need an additional kernel patch because nearly all
distros are using mach==i486 which gives you nice sigills on an i386
otherwise...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[William Lee Irwin III]

On Tue, 2003-10-14 18:33:49 +0100, John Bradford <john@grabjohn.com>
> wrote in message <200310141733.h9EHXnYg002262@81-2-122-30.bradfords.org.uk>:
>> No, 2.6 should run on a 4MB 386 with no significant performance
>> penalty against 2.0, in my opinion.

On Wed, Oct 15, 2003 at 02:43:14PM +0200, Jan-Benedict Glaw wrote:
> Achtually, with HZ at around 100 (or oven 70..80), an old i386 or i486
> will *start* just fine, at least at 8MB. However, over some days /
> weeks, the machine gets slower and slower (my testdrive: my 90MHz
> P-Classic with 16MB). Even with that "much" RAM, I get hit by whatever
> slows down the machine. I *think* that it's the MM subsystem, but I'm
> really not skilled enough with it to blame it:)

Well, unless it's an interrupts-safe critical section that's hurting,
you could take profiles, provided you have enough RAM for the profile
buffer (which appears to be large). You could easily do a quick hack
to steal the profile buffer from e820 regions not otherwise used for
RAM (i.e. unused because you did mem=) to handle that for a slow cpu
with more RAM than 8MB.


-- wli

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[William Lee Irwin III]

On Tue, 2003-10-14 18:27:05 +0200, Maciej Zenczykowski <maze@cela.pl>
> wrote in message <Pine.LNX.4.44.0310141813320.1776-100000@gaia.cela.pl>:
>> errnum->string. I'd expect that between 10-15% of the uncompressed kernel 
>> is currently pure text.

On Wed, Oct 15, 2003 at 01:45:14PM +0200, Jan-Benedict Glaw wrote:
> Right. For a real lowmem system (4MB RAM) I defined printk to a no-op
> and gained 90K at the compressed image IIRC. This was 2.2.x, though.
> MfG, JBG

The compressed image is hard to predict a runtime effect from; what did
it do to reserved memory at boot-time?


-- wli

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Nick Piggin]

Jan-Benedict Glaw wrote:

>On Tue, 2003-10-14 18:33:49 +0100, John Bradford <john@grabjohn.com>
>wrote in message <200310141733.h9EHXnYg002262@81-2-122-30.bradfords.org.uk>:
>
>>No, 2.6 should run on a 4MB 386 with no significant performance
>>penalty against 2.0, in my opinion.
>>
>
>Achtually, with HZ at around 100 (or oven 70..80), an old i386 or i486
>will *start* just fine, at least at 8MB. However, over some days /
>weeks, the machine gets slower and slower (my testdrive: my 90MHz
>P-Classic with 16MB). Even with that "much" RAM, I get hit by whatever
>slows down the machine. I *think* that it's the MM subsystem, but I'm
>really not skilled enough with it to blame it:)
>

Thats interesting. Its probably a memory leak I guess. Make sure to rule out
memory leaks in userspace applications, then get /proc/meminfo, 
/proc/slabinfo
on the box after it is getting slow, and also, after the box is newly 
booted.

Thanks

Re: Unbloating the kernel, action list

[William Lee Irwin III]

On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
>> Marco, if you could supply time on a small client box, and a desired .config,
>> we can add you as a Tinderbox client,
>>  then you have a place to point people when the size increases. 

On Wed, Oct 15, 2003 at 02:48:42PM +0200, Jan-Benedict Glaw wrote:
> I can put on the table:
> 486SLC, 12MB RAM
> i386, 8MB RAM (hey, this box is nearly build up by discrete parts:)
> Am386, 8MB RAM
> P-Classic, 32MB RAM (even that much RAM can go short after an uptme of
> about a month...)
> Unfortunately, you need an additional kernel patch because nearly all
> distros are using mach==i486 which gives you nice sigills on an i386
> otherwise...
> MfG, JBG

Can you quantify the performance impact of cmov emulation (or whatever
it is)? I have a vague notion it could be hard given the daunting task
of switching userspace around to verify it.


-- wli

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Wed, 2003-10-15 06:06:45 -0700, William Lee Irwin III <wli@holomorphy.com>
wrote in message <20031015130645.GJ765@holomorphy.com>:
> On Tue, 2003-10-14 18:27:05 +0200, Maciej Zenczykowski <maze@cela.pl>
> > wrote in message <Pine.LNX.4.44.0310141813320.1776-100000@gaia.cela.pl>:
> On Wed, Oct 15, 2003 at 01:45:14PM +0200, Jan-Benedict Glaw wrote:
> > Right. For a real lowmem system (4MB RAM) I defined printk to a no-op
> > and gained 90K at the compressed image IIRC. This was 2.2.x, though.
> > MfG, JBG
> 
> The compressed image is hard to predict a runtime effect from; what did
> it do to reserved memory at boot-time?

I'm not sure since this it's quite long ago (TM), but the effect was of
about 210K IIRC. The apps we had running on that box (think embedded)
*really* liked that 200K extra RAM. It made the difference between "swap
to death" and "nearly not swapping"...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, action list

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Wed, 2003-10-15 06:10:15 -0700, William Lee Irwin III <wli@holomorphy.com>
wrote in message <20031015131015.GR16158@holomorphy.com>:
> On Wed, Oct 15, 2003 at 02:48:42PM +0200, Jan-Benedict Glaw wrote:
> > I can put on the table:
> > Unfortunately, you need an additional kernel patch because nearly all
> > distros are using mach==i486 which gives you nice sigills on an i386
> > otherwise...
> 
> Can you quantify the performance impact of cmov emulation (or whatever
> it is)? I have a vague notion it could be hard given the daunting task
> of switching userspace around to verify it.

I can't. I'm haven't seen a really noticeable impact, but that doesn't
tell much:) However, there's no other chance than emulating cmov and
locked xchgs. If glibc/libstdc++ would go back, ABI would break and you
couldn't any longer copy programs build within one distribution over to
another.

So I think I'll diff out the patch and send it for review (note: it was
_not_ initially written by me!).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[H. Peter Anvin]

Followup to:  <20031015130614.GI765@holomorphy.com>
By author:    William Lee Irwin III <wli@holomorphy.com>
In newsgroup: linux.dev.kernel
> 
> Well, unless it's an interrupts-safe critical section that's hurting,
> you could take profiles, provided you have enough RAM for the profile
> buffer (which appears to be large). You could easily do a quick hack
> to steal the profile buffer from e820 regions not otherwise used for
> RAM (i.e. unused because you did mem=) to handle that for a slow cpu
> with more RAM than 8MB.
> 

Or just reduce mem= by enough less that you gain the profile buffer
back.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: Unbloating the kernel, action list

[Gabriel Paubert]

On Wed, Oct 15, 2003 at 06:10:15AM -0700, William Lee Irwin III wrote:
> On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
> >> Marco, if you could supply time on a small client box, and a desired .config,
> >> we can add you as a Tinderbox client,
> >>  then you have a place to point people when the size increases. 
> 
> On Wed, Oct 15, 2003 at 02:48:42PM +0200, Jan-Benedict Glaw wrote:
> > I can put on the table:
> > 486SLC, 12MB RAM
> > i386, 8MB RAM (hey, this box is nearly build up by discrete parts:)
> > Am386, 8MB RAM
> > P-Classic, 32MB RAM (even that much RAM can go short after an uptme of
> > about a month...)
> > Unfortunately, you need an additional kernel patch because nearly all
> > distros are using mach==i486 which gives you nice sigills on an i386
> > otherwise...
> > MfG, JBG
> 
> Can you quantify the performance impact of cmov emulation (or whatever
> it is)? I have a vague notion it could be hard given the daunting task
> of switching userspace around to verify it.

It can't be cmov emulation since neither 486 or Pentia have cmov, but
one of the following (differences between 386 and 486):

- cmpxchg: not used by UP kernels AFAICT, used by threading libraries,
  but maybe it's infrequent enough that it can be emulated

- xadd: can't tell whether it's used, could be emulated in any case
  since it looks so rare that you'll have to write specific code
  to exercise the emulator ;-)

- bswap: heavily used by network code at least, both applications and 
  kernel (ntohl/htonl). Emulation would probably be too expensive.

- invlpg: kernel only, easy to test and flush the whole TLB instead,
  perhaps even by boot-time patching of the code to minimize size.
  (I have no ideas of the number of occurences in an average kernel
  but it should be rather small).

- invd/wbinvd: only listed here for completeness :-)

The other problem of the 386 is that it has a fundamental MMU flaw:
no write protection on kernel mode accesses to user space, which makes 
put_user() intrinsically racy on a 386 and way more bloated when it is
inlined (access_ok has to call a function which searches the VMA tree).

	Regards,
	Gabriel

Re: Unbloating the kernel, action list

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

On Wed, 2003-10-15 20:16:58 +0200, Gabriel Paubert <paubert@iram.es>
wrote in message <20031015181658.GA9652@iram.es>:
> On Wed, Oct 15, 2003 at 06:10:15AM -0700, William Lee Irwin III wrote:
> > On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
> > Can you quantify the performance impact of cmov emulation (or whatever
> > it is)? I have a vague notion it could be hard given the daunting task
> > of switching userspace around to verify it.
> The other problem of the 386 is that it has a fundamental MMU flaw:
> no write protection on kernel mode accesses to user space, which makes 
> put_user() intrinsically racy on a 386 and way more bloated when it is
> inlined (access_ok has to call a function which searches the VMA tree).

However, this problem exists since the very first hour. Linux once
really ran quite well on those machines...

I've rebooted my P-Classic router last night. Maybe I can see (in two
weeks or in a month or the like...) why it slows down, even with 32MB
RAM...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, action list

[Gabriel Paubert]

On Thu, Oct 16, 2003 at 07:19:51AM +0200, Jan-Benedict Glaw wrote:
> On Wed, 2003-10-15 20:16:58 +0200, Gabriel Paubert <paubert@iram.es>
> wrote in message <20031015181658.GA9652@iram.es>:
> > On Wed, Oct 15, 2003 at 06:10:15AM -0700, William Lee Irwin III wrote:
> > > On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
> > > Can you quantify the performance impact of cmov emulation (or whatever
> > > it is)? I have a vague notion it could be hard given the daunting task
> > > of switching userspace around to verify it.
> > The other problem of the 386 is that it has a fundamental MMU flaw:
> > no write protection on kernel mode accesses to user space, which makes 
> > put_user() intrinsically racy on a 386 and way more bloated when it is
> > inlined (access_ok has to call a function which searches the VMA tree).
> 
> However, this problem exists since the very first hour. Linux once
> really ran quite well on those machines...

Yes, but VM sharing between threads was rather infrequent back then
and you need shared VM to create the race.

> 
> I've rebooted my P-Classic router last night. Maybe I can see (in two
> weeks or in a month or the like...) why it slows down, even with 32MB
> RAM...

It might be related to the size-4096 memory leak others are reporting 
right now. I don't know, but it's not such a far-fetched hypothesis
either.

	Gabriel

Re: Unbloating the kernel, action list

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Thu, 2003-10-16 10:16:11 +0200, Gabriel Paubert <paubert@iram.es>
wrote in message <20031016081611.GA14949@iram.es>:
> On Thu, Oct 16, 2003 at 07:19:51AM +0200, Jan-Benedict Glaw wrote:
> > On Wed, 2003-10-15 20:16:58 +0200, Gabriel Paubert <paubert@iram.es>
> > wrote in message <20031015181658.GA9652@iram.es>:
> > > On Wed, Oct 15, 2003 at 06:10:15AM -0700, William Lee Irwin III wrote:
> > > > On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
> > I've rebooted my P-Classic router last night. Maybe I can see (in two
> > weeks or in a month or the like...) why it slows down, even with 32MB
> > RAM...
> 
> It might be related to the size-4096 memory leak others are reporting 
> right now. I don't know, but it's not such a far-fetched hypothesis
> either.

size-4096 only decreased (!) by one since reboot. However, size-64 seems
to be sloooowly growing:

jbglaw@gatter:~$ grep size-64 slabinfo_after_reboot /proc/slabinfo |cut -b 1-60
slabinfo_after_reboot:size-64(DMA)           0      0     64
slabinfo_after_reboot:size-64             2655   2655     64
/proc/slabinfo:size-64(DMA)           0      0     64   59  
/proc/slabinfo:size-64             2883   6608     64   59  

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Wed, 2003-10-15 23:08:39 +1000, Nick Piggin <piggin@cyberone.com.au>
wrote in message <3F8D46D7.1020105@cyberone.com.au>:
> Jan-Benedict Glaw wrote:
> >On Tue, 2003-10-14 18:33:49 +0100, John Bradford <john@grabjohn.com>
> >wrote in message 
> ><200310141733.h9EHXnYg002262@81-2-122-30.bradfords.org.uk>:

> >Achtually, with HZ at around 100 (or oven 70..80), an old i386 or i486
> >will *start* just fine, at least at 8MB. However, over some days /
> >weeks, the machine gets slower and slower (my testdrive: my 90MHz
> >P-Classic with 16MB). Even with that "much" RAM, I get hit by whatever
> >slows down the machine. I *think* that it's the MM subsystem, but I'm
> >really not skilled enough with it to blame it:)
> >
> 
> Thats interesting. Its probably a memory leak I guess. Make sure to rule out
> memory leaks in userspace applications, then get /proc/meminfo, 
> /proc/slabinfo
> on the box after it is getting slow, and also, after the box is newly 
> booted.

Well, the box is still fine useable, but it's only rebooted some days
ago. However, I see size-64 (non-DMA) is going sloooowly up... What do I
do with the box? minicom (it's kind of a console server:), NATting, IPv6
gw. No X11, normally no local access at all.

On my Athlon (dual), I've already reached 319780 allocations in size-64,
but it seems to be currently stable, though...

I do _not_ see a leak in he size-4k region.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, action list

[M. Fioretti]

On Tue, Oct 14, 2003 15:30:41 at 03:30:41PM -0700, Martin J. Bligh (mbligh@aracnet.com) wrote:
> 
> > 7) Do come in suggesting anything I might have forgotten
> 
> If you do automated testing of nightly builds of the mainline 2.6 / 2.7
> kernels, and point out when they get bigger in consumption, you'll have
> a much better chance of convincing people to fix it when the patch in
> question is still topical, and fresh in people's minds.

I agree. Unfortunately, I have no possibility to do this. I'll pass it
over to the RULE list, though.

> I'd predict that a lot of the issue is just tuning things dynamically 
> instead of statically sizing them.

That makes sense. From our point of view, the best thing would be
pointers to resources explaining what to tune, when and why, so we can
prepare suitable documentation from that for our non technical end
users. Suggestions?

TIA,
	Marco Fioretti

-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

I doni ricevuti dal Padreterno, servono se utilizzati: chi li contempla
gode, ma chi ne fa uso probabilmente aiuta altri a godere.

Re: Unbloating the kernel, action list

[M. Fioretti]

On Wed, Oct 15, 2003 14:48:42 at 02:48:42PM +0200, Jan-Benedict Glaw (jbglaw@lug-owl.de) wrote:
> On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@osdl.org>
> wrote in message <20031014155638.7db76874.cliffw@osdl.org>:
> > On Tue, 14 Oct 2003 15:30:41 -0700
> > "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> > > > 7) Do come in suggesting anything I might have forgotten
> 
> > Marco, if you could supply time on a small client box, and a desired .config,
> > we can add you as a Tinderbox client,
> >  then you have a place to point people when the size increases. 
> 
> I can put on the table:
> 
> 486SLC, 12MB RAM
> i386, 8MB RAM (hey, this box is nearly build up by discrete parts:)
> Am386, 8MB RAM
> P-Classic, 32MB RAM (even that much RAM can go short after an uptme of
> about a month...)
> 

Jan,
if you have time, I'd appreciate if you could register them also in
our test database (), install RULE on them and let us know what happens.

TIA,
	Marco Fioretti

-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

Nature is very un-American.  Nature never hurries.
						-- William George Jordan

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Nick Piggin]

Jan-Benedict Glaw wrote:

>On Wed, 2003-10-15 23:08:39 +1000, Nick Piggin <piggin@cyberone.com.au>
>wrote in message <3F8D46D7.1020105@cyberone.com.au>:
>
>>Jan-Benedict Glaw wrote:
>>
>>>On Tue, 2003-10-14 18:33:49 +0100, John Bradford <john@grabjohn.com>
>>>wrote in message 
>>><200310141733.h9EHXnYg002262@81-2-122-30.bradfords.org.uk>:
>>>
>
>>>Achtually, with HZ at around 100 (or oven 70..80), an old i386 or i486
>>>will *start* just fine, at least at 8MB. However, over some days /
>>>weeks, the machine gets slower and slower (my testdrive: my 90MHz
>>>P-Classic with 16MB). Even with that "much" RAM, I get hit by whatever
>>>slows down the machine. I *think* that it's the MM subsystem, but I'm
>>>really not skilled enough with it to blame it:)
>>>
>>>
>>Thats interesting. Its probably a memory leak I guess. Make sure to rule out
>>memory leaks in userspace applications, then get /proc/meminfo, 
>>/proc/slabinfo
>>on the box after it is getting slow, and also, after the box is newly 
>>booted.
>>
>
>Well, the box is still fine useable, but it's only rebooted some days
>ago. However, I see size-64 (non-DMA) is going sloooowly up... What do I
>do with the box? minicom (it's kind of a console server:), NATting, IPv6
>gw. No X11, normally no local access at all.
>
>On my Athlon (dual), I've already reached 319780 allocations in size-64,
>but it seems to be currently stable, though...
>
>I do _not_ see a leak in he size-4k region.
>

Maybe you could try Manfred's recent patch (in this thread) to find out
what is kmallocing all that memory.

Re: Unbloating the kernel, action list

[Adrian Bunk]

On Wed, Oct 15, 2003 at 05:05:30PM +0200, Jan-Benedict Glaw wrote:
>...
> locked xchgs. If glibc/libstdc++ would go back, ABI would break and you
> couldn't any longer copy programs build within one distribution over to
> another.
>...

It's only libstdc++, and the libstdc++ ABI will change again in the 
forseeable future.

> MfG, JBG

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Unbloating the kernel, action list

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Sun, 2003-10-19 13:21:41 +0200, Adrian Bunk <bunk@fs.tum.de>
wrote in message <20031019112141.GN12423@fs.tum.de>:
> On Wed, Oct 15, 2003 at 05:05:30PM +0200, Jan-Benedict Glaw wrote:
> >...
> > locked xchgs. If glibc/libstdc++ would go back, ABI would break and you
> > couldn't any longer copy programs build within one distribution over to
> > another.
> It's only libstdc++, and the libstdc++ ABI will change again in the 
> forseeable future.

I was told by others that exactly this won't happen again in the
foreseeable future... If it did, I'll *love* so see it change, though:-)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[bill davidsen]

In article <Pine.LNX.4.44.0310141813320.1776-100000@gaia.cela.pl>,
Maciej Zenczykowski  <maze@cela.pl> wrote:

| On one hand I agree with you - OTOH: why not run an older version of the
| kernel? Are kernel versions 2.2 or even 2.0 really not sufficient for such
| a situation?  It should be noted that newer kernels are adding a whole lot
| of drivers which aren't much use with old hardware anyway and only a
| little actual non-driver related stuff (sure it's an oversimplification,
| but...).  Just like you don't expect to run the latest
| games/X/mozilla/kde/gnome on old hardware perhaps you shouldn't run the
| latest kernel... perhaps you should...
| 
| Sure I would really like to be able to compile a 2.6 for my 
| firewall (486DX33+40MB-2MB badram) - but is this the way to go?

The problem is that you can make a much better firewall with iptables,
so going to at least 2.4.xx is very desirable. The 2.4->2.6 change is
the first one in a long time which didn't rewrite the network code in a
major way, such as ipfwadm -> ipchains -> iptables. I don't see the
IPsec and crypto in-kernel as a big gain, freeswan was a patch and in
kernel or in a shared library is similar in memory use.

Clearly the in-kernel is faster.

| As for making the kernel smaller - perhaps a solution would be to code all 
| strings as error codes and return ERROR#42345 or something instead of the 
| full messages - there seem to be quite a lot of them.  I don't mean to 
| suggest this solution for all compilations but perhaps a switch to remove 
| strings and replace them with ints and then a seperately generated file of 
| errnum->string. I'd expect that between 10-15% of the uncompressed kernel 
| is currently pure text.

This really needs to be done as part of i18n, where a format is replaced
by an int which is an index into the local format string table. This is
very hard to do right, since the strings all need to be unique, implying
a registration. Note: please don't read "needs to be done" without the
i18n part, I'm saying that if it were to be done it should be done to
allow for i18n string tables, not that this is a critical feature!
| 
| Perhaps int->string conversion could be done by a loadable module or a 
| userspace program?

I would say tes and no, respectively.

| Of course part of the problem is that by designing the kernel for high mem 
| situations we're using more memory hogging algorithms.  It's a simple 
| matter of features vs mem footprint.

There are three (at least) driving forces:
1 - nifty new features, hopefully can be configurable
2 - algorithms needed to run on large hardware. I think in some cases
    this could be done by defining small-mem vs. big-mem macros, but it
    takes a bit of work and requires regular testing of both paths.
3 - speed vs. memory. This is sort of a subcase of (2), where only the
    very smallest machines would feel a pinch. That is, they are
    generally useful, rather than intended to support derver and cluster
    class hardware.

So (1) can be configurable if people are willing, (2) would require
implementation of an alternate code, and (3) is probably part of the
cost of a new kernel.

If people feel strongly 2.7 could start to go to mudules and/or having a
set of definitions optimized for various configurations. Before you say
that can't be done, consider that we now support a bunch of totally
unlike hardware, so it's certainly possible.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[bill davidsen]

In article <3F8CE3EB.8040907@storm.ca>, Sandy Harris  <sandy@storm.ca> wrote:
| jlnance@unity.ncsu.edu wrote:
| 
| > Let me concur with the sentiments on this thread.
| 
| Me too.
| 
| > ...  There are many people who will never be able to afford
| > to buy a computer but could find someone to give them one of these
| > "hopelessy outdated" machines for nothing.
| 
| Some people may be able to get more than one. A year or two
| back a peniless friend of mine built quite a nice environment
| for himself with two 486 boxes and a pile of SPARC IIs.
| 
| Also, there are server applications that don't need much. For
| example, a firewall and NAT box for an ADSL line, or a print
| spooler or ...
| 
| You could even build a Beowulf out of such machines
| http://stonesoup.esd.ornl.gov/
| 
| > If we can ensure that
| > Linux keeps working on these machines, it will be a good thing.

Agreed, until you start to talk cluster. If you pay for electricity, newer
machines use less per MHz. One of those $200 "Lindows" boxen from
Wal-Mart starts to look good about the 2nd old Pentium!
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[M. Fioretti]

On Fri, Oct 24, 2003 15:59:33 at 03:59:33PM +0000, bill davidsen (davidsen@tmr.com) wrote:

> | > If we can ensure that Linux keeps working on these machines, it
> | > will be a good thing.
> 
> Agreed, until you start to talk cluster. If you pay for electricity,
> newer machines use less per MHz. One of those $200 "Lindows" boxen
> from Wal-Mart starts to look good about the 2nd old Pentium!

May I ask you to elaborate on this? Less per MHz doesn't matter much
if the frequency is much higher, or it does? I mean, if you put, say,
a 133 MHz pentium and a 1 GB pentium to do the same thing with the
same SW (mail server, for example), the 1GB system may use less per
MHz (newer silicon, lower voltage, etc...) and its flip-flops toggle
for a smaller percentage of time, but its electricity bill will still
be the higher one, or not?

In general: has anybody ever done *this* kind of benchmarks? Comparing
electricity consumption among different systems doing just the same
task?

TIA,
	Marco Fioretti

-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

A good man is intelligent, and a bad man is also an idiot. Moral and
intellectual characteristics go together - Jorge Luis Borges

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[bill davidsen]

In article <20031024165553.GB933@inwind.it>,
M. Fioretti <m.fioretti@inwind.it> wrote:
| On Fri, Oct 24, 2003 15:59:33 at 03:59:33PM +0000, bill davidsen (davidsen@tmr.com) wrote:
| 
| > | > If we can ensure that Linux keeps working on these machines, it
| > | > will be a good thing.
| > 
| > Agreed, until you start to talk cluster. If you pay for electricity,
| > newer machines use less per MHz. One of those $200 "Lindows" boxen
| > from Wal-Mart starts to look good about the 2nd old Pentium!
| 
| May I ask you to elaborate on this? Less per MHz doesn't matter much
| if the frequency is much higher, or it does? I mean, if you put, say,
| a 133 MHz pentium and a 1 GB pentium to do the same thing with the
| same SW (mail server, for example), the 1GB system may use less per
| MHz (newer silicon, lower voltage, etc...) and its flip-flops toggle
| for a smaller percentage of time, but its electricity bill will still
| be the higher one, or not?

Presumably a cluster exists to do more work than can be done on a single
machine. So a single cheap low power modern system will probably use a
lot less power to do equal work. Perhaps MHz was a poor choice, but we
don't really have a good single term for an arbitrary unit of computing
(AUC?) which is what I really meant there. At some point a cluster of
old slow machines doesn't scale financially, even if they are free.
Admin and repair tend to scale with units, networking is needed which
drives up the cost, even if time is free it's still finite.

| In general: has anybody ever done *this* kind of benchmarks? Comparing
| electricity consumption among different systems doing just the same
| task?

If same task means the same number of AUC, say web pages served,
probably you could find that somewhere. Or measure a 486, a P4 and a C3
compiling a kernel. If the 486 takes about 80 minutes (from memory
that's close), and a P4-2.6 takes about 8 minutes, then if the P4 takes
less than ten times the power of the 486 it would be more efficient in
terms of computations per watt. I have never compiled a kernel on the
C3, but I suspect it is at least 5x the 486 and takes much less power.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Geert Uytterhoeven]

On 24 Oct 2003, bill davidsen wrote:
> In article <20031024165553.GB933@inwind.it>,
> M. Fioretti <m.fioretti@inwind.it> wrote:
> | On Fri, Oct 24, 2003 15:59:33 at 03:59:33PM +0000, bill davidsen (davidsen@tmr.com) wrote:
> | > Agreed, until you start to talk cluster. If you pay for electricity,
> | > newer machines use less per MHz. One of those $200 "Lindows" boxen
> | > from Wal-Mart starts to look good about the 2nd old Pentium!
> | 
> | May I ask you to elaborate on this? Less per MHz doesn't matter much
> | if the frequency is much higher, or it does? I mean, if you put, say,
> | a 133 MHz pentium and a 1 GB pentium to do the same thing with the
> | same SW (mail server, for example), the 1GB system may use less per
> | MHz (newer silicon, lower voltage, etc...) and its flip-flops toggle
> | for a smaller percentage of time, but its electricity bill will still
> | be the higher one, or not?
> 
> Presumably a cluster exists to do more work than can be done on a single
> machine. So a single cheap low power modern system will probably use a
> lot less power to do equal work. Perhaps MHz was a poor choice, but we
> don't really have a good single term for an arbitrary unit of computing
> (AUC?) which is what I really meant there. At some point a cluster of

MIPS/mW, like they do for embedded CPUs?

> | In general: has anybody ever done *this* kind of benchmarks? Comparing
> | electricity consumption among different systems doing just the same
> | task?
> 
> If same task means the same number of AUC, say web pages served,
> probably you could find that somewhere. Or measure a 486, a P4 and a C3
> compiling a kernel. If the 486 takes about 80 minutes (from memory
> that's close), and a P4-2.6 takes about 8 minutes, then if the P4 takes
> less than ten times the power of the 486 it would be more efficient in
> terms of computations per watt. I have never compiled a kernel on the
> C3, but I suspect it is at least 5x the 486 and takes much less power.

The C3 is OK, I guess. But the P4 (the CPU) consumes probably about 10 times as
much power as the 486.

Of course you also have to take into account disk and RAM, etc.

Yes, MIPS/mW ratio for your desktop CPU looks very bad compared to e.g. PPC440,
StrongARM, or Vr4133...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Unbloating the kernel, was: :mem=16MB laptop testing

[Rob Landley]

On Friday 24 October 2003 11:55, M. Fioretti wrote:
> On Fri, Oct 24, 2003 15:59:33 at 03:59:33PM +0000, bill davidsen 
(davidsen@tmr.com) wrote:
> > | > If we can ensure that Linux keeps working on these machines, it
> > | > will be a good thing.
> >
> > Agreed, until you start to talk cluster. If you pay for electricity,
> > newer machines use less per MHz. One of those $200 "Lindows" boxen
> > from Wal-Mart starts to look good about the 2nd old Pentium!
>
> May I ask you to elaborate on this? Less per MHz doesn't matter much
> if the frequency is much higher, or it does? I mean, if you put, say,
> a 133 MHz pentium and a 1 GB pentium to do the same thing with the
> same SW (mail server, for example), the 1GB system may use less per
> MHz (newer silicon, lower voltage, etc...) and its flip-flops toggle
> for a smaller percentage of time, but its electricity bill will still
> be the higher one, or not?
>
> In general: has anybody ever done *this* kind of benchmarks? Comparing
> electricity consumption among different systems doing just the same
> task?

Yes.  IBM did.  They were used it as a big arument in favor of linux on the 
mainframe instead of beowulf circa 2000 or so.  (In serious server room 
environments, you have to pay the electricity bill twice.  Once to power the 
systems and once for the air conditioning to remove the heat created by 
powering the systems... :)

Rob