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.
2.6 hasn't had the long real-life test use that the 2.4 family has. However, that isn't to say that 2.6 has been ignored by the distro kings, just not their staple offering, which would need to be absolutely assured of stability and compatibility.
Example, Suse 9 came with a copy of 2.4.21-144 which it installed and then gave you the sources and information needed if you wanted to update to 2.6. So, yes, it's out there, and it's in major distros, but not having the absolute assuredness of the 2.4 line, 2.6 is left as a secondary option.
YOU SUCK BALLS!
How does 2.6 compare to Free or Open BSD & how do they compare to windows 2003 server doing the same job?
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
I guess it's important to ask the following question: was 2.4 ever designed to run on those kinds of processors? I mean, the O(1) scheduler is a pretty cool, processor independant change; but was 2.6 designed with specific optimizations for newer processors (and newer instructions) in mind? I'd be interested to see benchmarks from old hardware -- i.e., stuff like I've got sitting around. (If only I had a bit more time. Maybe I can borrow some cycles from 2.6 Linux boxen.)
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.
These are some pretty encouraging results. The hard work put in by all the kernel developers has obviously paid off in a big way. However, after reading the article I still have a few questions about kernel 2.6 performance, namely filesystem performance. Rapid random read/write access is obviously highly critical for enterprise type applications, such as apt-get package management and package database updates. Basically with the 2.4.x series of kernels, filesystem performance using either the ext2 or ext3 schemes could drop to below 5 apt-get package installs per second, even on large SMP/RAID systems. I have been investigating the use of raw disk I/O (similar to that used for high performance table spaces in products like Oracle and DB2) to reach my target of 100 apt-get package installations per second on commodity level hardware, via custom kernel level ATA and SCSI chipset drivers. But I'd love to hear that FS speeds have been improved in the 2.6 kernel. Has anybody benchmarked this aspect of the new kernel? And if so, when could we expect to see Debian start shipping with the 2.6 kernel? I look forward to reading the community's response.
linux 7.0??? I thought we were only on 2.6 or is this referring to a given disto? if so what? redhat? suse? in either case thats a rather old version.
A full Windows installation, compared to installing Linux, on an Enterprise Server boxen: * Is nearly three hours faster.
* Requires 77% fewer steps.
Your average linux distro installs a hell of a lot more and does a hell of a lot more than a windows installation does. Unless full installation means all the other stuff you have to install manually after.
Next in order to verify numbers like that any right minded person would like to see exactly what was being done, how things were configured (like what optimisation steps were taken on both platforms).
These numbers are just marketing crap, they are meaningless without any detail. Just as figures promoting linux in the same light would be!
Copyright (c) 2004 Mike Bouma, MCSE, MCDST, MS Office Specialist
Yes your definatley better qualified to believe microsoft marketing numbers than many on here who actually have a CS degree, work in kernel dev etc.
Its my experience that "highly trained technical professionals" would have enough real world experience to know the sort of crap code that can come out of any company...no matter how much money you throw at it, and that there's nothing inherently better about a product that costs money. In fact, it's been my experience that the more you pay for something, the crappier it is *cough*legato*cough*
Also, professional you may be (as in you get payed to do it), but you have very little professionalism if you have to resort to using terms like "open sores", not to mention the fact that you haven't got a clue what you're talking about due to your use of terms like "the Linux 7.0 webserver", "LinuxOS", and reference to RedHat as a web server, as well as referring to J2EE as an open source product, instead of the specification implemented by many proprietry application servers by companies such as IBM, Oracle, Borland and BEA.
I'm not even sure why I'm replying to this...it might as well have been generated by a script...
Advanced users are users too!
The comparisons won't make much real-world sense until the evaluation is done using Intel's compiler for the Itanium tests. The GNU compiler is just not up to snuff at optimizing for Itanium's EPIC instruction set.
I would like to see Intel contribute Itanium optimizations to GNU, but I doubt this will happen since they sell a competing product.
the growth in cynicism and rebellion has not been without cause
I wonder what the response would be if someone posted similar numbers about Microsoft's next OS. I'm sure they'd find creative ways to diminish the results.
One thing I've learned is not to take tech writers too seriously. Most of them are writers for a reason.
-- You see, there would be these conclusions that you could jump to
It was a joke that went way over your head.
For Windows, the cost was only:
$40.25 per megabit of throughput per second.
$1.79 per peak request per second.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Most of it has to do with the algorithms. For example I can write a really optimized bubble search but if you write an un optimized quick sort it will still be faster than my optimized bubble search. That being said any newbie programmer can do a bubble search but you have to know what you're doing to do a quick/merge sort.
So while 2.4 wasn't using the best solutions it was better than nothing. It's always better to have bad working code than great code that doesn't work. Hurd is a great example. It may be batter but it doesn't work (well enough for me anyway) yet so who cares.
IDE is another example. If I remember correctly 2.2 didn't have DMA support but it worked adding DMA makes it much faster but it would have made it more unstable if they added it at the beginning.
The last thing that you have to remember is that lots of the changes were taking advantage of features in the newer hardware. If you ran the same test on 486 you wouldn't get the same results as you'd have different bottlenecks. In another 10 years we'll get the same thing again. The might make it so that the bus to the memory is as faster as the level 2 cache on the CPU. If they do that they'll have to make big changes to the OS to get rid of the new bottle necks and you'd increase the speed by another 50% or maybe even 100%
Anyway that's enough ranting.
A kernel is much more complex than a single program. A program usually does one thing, and once you've optimized that, that's all there really is. In contrast, a kernel does all sorts of things. 2.2 was good for small-scale servers. 2.4 was good for mid-range servers. 2.6 is good for larger servers and desktop machines. 2.8 is supposed to get improvements to make it better on desktops and on huge NUMA machines. Linux has always been a fast kernel for what it did, its just that its doing a lot more today than it did a few years ago.
A deep unwavering belief is a sure sign you're missing something...
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.
Sun does sell some machines that run Solaris and have x86 processors in them. They sell one Athlon (Mobile Athlon, actually -- it's in a blade server) and several dual Xeon systems. (See here.) So it's not as if the x86 version of Solaris is totally the ugly stepchild of the Sun family.
Plus, yeah, it's helpful to get into assembly to write good context switch code and MMU stuff and whatnot, but how much of the scheduling and scalability is really based on platform-specific optimizations? I think most of it is due to choosing a good design and good algorithms. Especially these days, when raw CPU is no longer the problem because CPUs are so fast. My point is that I think lots of the value in the Solaris kernel translates to any architecture -- like a fully pre-emptable kernel, and design decisions that minimize contention for locks and things like that.
Don't blame the kernel for that fact that some of your applications are memory hogs. I would be willing to bet money that your problem is a lack of RAM. In which case, the only involvement the kernel has is that a better paging algorithm could be the difference between very atrocious performance and very very atrocious performance. There is no way that any kernel is going to wow you; it's like having four flat tires on your car and driving around on the rims, then saying that you weren't impressed by the performance improvement you got from installing a new carburetor.
I too, by the way, once had an old Dell with a Pentium 200 and 64 MB of RAM. One thing you'll find is that you can add more RAM, but if you have the same crappy Intel chipset I did, anything more than 64 MB will not be cached, and the limit for total memory is probably 128 MB. (Sad, huh?)
Sweet! This was my one pet peeve when using Linux on a production server, such as a tape backup systems.
For every problem there is a solution that is simple, obvious and wrong.
I may be the only one to feel this way... but haven't the completely unrelated SCO jokes gotten a little old? They are completely offtopic 99% of the time and most of them are just "Where do I send my 699 dollars".
Who do you think we professionals trust more?
Reliable companies with tried and tested products, or that bedroom coder Thorwalds who publicly admits that he is in fact A HACKER???
Hats off to you good sir! The funniest troll I've seen in a while. Actually had me about ready to engage in a shouting fit till that last line. Hilarious.
Putting the post under a GPL, genius!
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Sarcasm just goes WAY over your head, doesn't it?