Messages in this thread | | | From | Andrew Derrick Balsa <> | Subject | Re: Memory Rusting Effect [re: Linux hostile to poverty] | Date | 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
| |