Slashdot Mirror
2.4 vs 2.6 Linux Kernel Shootout
FyRE666 writes "Infoworld are currently running an interesting comparison of the 2.4 series kernel against the new 2.6 release on Xeon, Opteron and Itanium CPUs with some surprising benchmark results for common server-related tasks. Basically the new scheduler helps the 2.6 kernel to cream the old 2.4: Samba tests showing up to 73% speed increases, MySQL showing up to 29% and Apache serving dynamic content up to 47% faster!"
Those benchmarks are nice, but who runs kernel 2.6 on production servers that need every speed they can get? It will be a few more 2.6.x releases until I consider running one of my servers with a 2.6 kernel.
Pain is merely failure leaving the body
Caching is controlled completely by the CPU, transparent of the programmer.
:).
Assuming that the kernel is the only code running, and it is small enough to fit into cache, then it will get there eventually.
However, it would make no sense to keep the entire kernel in cache, since most of that code isn't used most of the time. Also, application software is running at the same time, which needs to be cached as well.
In other words, just trust the CPU. It knows what it's doing
Actually, it wouldn't suprise me if this is correct. If you notice, he was reading the 500MB file while a continuous streaming write was going on in the background. On 2.4.x, a write streamout will kill read performance drastically. Mostly due to the way the I/O scheduler schedules the read. Which, most of the time, is to stash it at the end of the writes.
The two new I/O schedulers in 2.6.x help to resolve this. For more info, check here.
The old kernel had a lot of room for improvement on the systems they tested; but that's primarily due to the fact that the systems are substantially newer than the 2.4 series. A 2 GB dual Xeon system running 2.4 isn't going to use the processors efficiently (hyperthreading, imprecise locks), and isn't going to deal with the memory effectively. It was in part to take advantage of the availablity of such systems that the changes for 2.6 were made.
New conditions require new optimizations and new designs; a good program optimized for a set of inputs which are common at one time may be really inefficient at handling inputs that become common later. Sure, you can make a program that's good for both sorts of input, but it doesn't make sense to try to do so until someone actually has such an input to test with.
Sarcasm just goes WAY over your head, doesn't it?