In a reply on Linux kernel maling list to Aaron Lehmann’s praising of the contest results of the latest 2.5-mm kernel Andrew Morton explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks. Read the report at KernelTrap.
Andrew Morton on Linux 2.5’s Performance Improvements
2002-11-16 Linux 12 Comments
2.6/3.0 is going to be sweet! 🙂
-fooks on 2.5.47-mm1
Is da bomb
I wish that it was next september already 🙁
I ran 2.5.40-45 without any problems and I really noticed a difference in responsivness even though my current kernel are using pretty much all the good stuff backported (rmap, etc), only thing holding me back from completely replacing my old kernel is that the nvidia kernel still doesn’t officially support 2.5 kernel.
ACPI are replacing PNP in many ways in 2.5, but the ACPI still refuse to compile for me so I have to use the older stuff, looking forward to disabling APM/PNP and all that ACPI replaces once that’s fixed in 2.5.
Once that happen, Zooom, I’m on the 2.5 train.
make -j30 bzImage whats the -j do?
..replacing my old kernel is that the nvidia kernel still doesn’t officially support 2.5 kernel.
Go to http://www.minion.de/nvidia.html and get the patches. The work beautifully and are supposed to have fixed the famous memory allocation bug present in 2.4.x kernels. I’ve been running with these drivers for over 2 weeks now, rock solid. Only rebooting for the kernel upgrades 🙂
make -j 30 specificies how many simultaneous jobs should run.
-j[number] option for make starts [number] jobs simultaneously.
is that it does not perform as well as a pure 2.5.x/2.6.x kernel as other parts are tweaked to get better performence out of the new stuff etc.
I’m running kernel 2.5.46 here (unpacking 2.5.47 now , and I must say, the “polish” level is up a bit. I’ve never reallly had any responsiveness problems in Linux after the preempt patches were introduced, so I don’t really notice anything major. However, an emerge (big compile) running in the background is now completely unnoticable, as opposed to before where it was just barely noticible. One thing I’d like to see in Linux, however, is support for giving I/O priories. On my machine, I have enough RAM that the system can queue up quite a few requests to the disk. If I’m running something like a big compile, then try to start an application from KDE, the request to go fetch the application from disk will get stuck behind all those requests from the compiler, and it can be several seconds before the application can load. That said, that’s pretty much the only performance issue I notice these days.
Thanks for the link Fooks, but in the end it proved that the Gentoo people already had added that patch so it was auto-applied this time around when I emerged nvidia-kernel (it wasn’t last time I tried 2.5.x tree).
This is really snappy.