Re: Memory Rusting Effect [re: Linux hostile to poverty]

Andrew Derrick Balsa (andrebalsa@altern.org)
Sat, 18 Jul 1998 16:07:01 +0200


Martin Mares wrote:
....
>
> It's already on my console TODO list, but just now I don't have any monochrome
>cards here, so I cannot test it well. If you have one, I can send a patch to you
>for testing.

Sorry Martin, I have two machines with monochrome adapters, but:

- Machine 1 is an AMD 386DX-40 box with 4 Mb of RAM, 120Mb hard disk, running an
early 2.0.x kernel version. It has been rebooted about once every 6 months for
the last 18 months. Running Apache 1.1.x and some other daemons. Obviously I
can't test 2.1.10x kernels on this box (and don't want to, even though I would
really appreciate the improved network performance).

- Machine 2 is an Intel 486DX2-66 with 8Mb of RAM, heavily used as a Samba
server. Also runs an early 2.0.x kernel. Since it's a production machine, I am
also not allowed to make tests on it, idem as Machine 1.

Late Linux 2.1.1x kernels are indeed hostile to old equipment, but
unfortunately most such equipment is used as "production" Linux boxes.

There is obviously a conflict between the need to support "legacy" hardware and
the desire of developpers to push the enveloppe of new kernels by adding
code/features. That's what my post was about. IMHO the trade-off between
performance and complexity should be solved in the following way:

If adding complexity for "special" cases --> favour simplicity.
If adding complexity for the general case --> favour performance, but also keep
an eye on keeping complexity down.

If there is one thing experience tells us, it's that the simplest solutions
very often perform quite well. Sorry if that's an awfully generic statement,
but it's true all the same.

In CPU architecture terms, this means keeping the execution path as clean as
possible, and it leads to the MIPS, SPARC and Alpha designs.

In kernel programming terms, it means keeping the code for the general case
short and simple, which I think is generally what Linus, you and others try to
achieve. I just think the MM code took the wrong turn some time ago, and never
recovered :-(

Best regards,
---------------------
Andrew D. Balsa
andrebalsa@altern.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html