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!"

Comments

Error

[popa]

tried to get this in before you posted it... but dynamic only went up 22% for apache.... static went up 47%

And SCO shows...

[Black Parrot]

...a stunning 129% increase on SPEClawsuit!

drugs are bad

[POds]

Okay, who's been feeding 2.6 speed?

Re:drugs are bad

[Rosco P. Coltrane]

Okay, who's been feeding 2.6 speed?

IBM, according to SCO.

May try it then

[Anonymous Coward]

I was wondering about upgrading to 2.6 from 2.4 with XFS on my box, with the improvements to SCSI support and the CPU speed ups it sounds promising :D

Then again BSD is very nice on the same hardware. Wonder how 2.6 linux & (free)BSD compare for those tasks.

Re:May try it then

[anthonyrcalgary]

Try them both to see which one is faster/you like more. And don't listen to anyone who tells you not to try the alternatives, they're probably zealots.

Don't let my sig fool you, I like Gentoo better on the desktop. It's just that little bit more convenient to get the latest everything.

Some stuff I can tell you:

• With ULE enabled on FreeBSD 5.2, I can't tell the difference. No formal benchmarks, but I did everything I could to expose stuff that might annoy me later on. Dragging windows around really fast with "display content in moving windows" on and music playing. The sort of thing that would bring Linux 2.4 to its knees easily
• FreeBSD 5.2 has some annoying things. Like you've got to manually enable the drivers for sound devices and USB mice. And you've got to recompile the kernel to get ext2 support. It's pretty easy and well documented, but you can't just install and have a working system with no additional work.
• Gentoo didn't (for me) have any major issues. I mean, compile times can be a bitch, but you'll be doing that on FreeBSD eventually too.
• FreeBSD can do some really nifty stuff that Linux can't. Like jails.

My advice is to wait until FreeBSD 5 hits STABLE and Linux 2.6 matures a little bit, install both, and see what's more fun.

Impressive

[mgv]

These are impressive improvements.

Its actuallly hard to believe that there is that much more improvement to be gained - it will leave the microsoft servers even further behind as I don't think that they are improving their kernel that fast.

One question:

Does this mean that we can see improvements in low end systems for desktop use, or is the benefit only for servers. Because if this helps low end machines, it extends further the number of machines that can move from (say) win 98 to a real OS, whose hardware has long been abandoned by microsoft.

Michael

Re:Impressive

[JebusIsLord]

well i know the preemtive and low-latency changes (while available as patches to 2.4) are included in 2.6, and make a significant difference to GUI responsiveness.

Re:Impressive

[zmooc]

I can now watch divx on my pII-233 with it. Xmms never skips and X remains useable under high loads. It's an incredibly huge difference to 2.4. But I only noticed when I had to go back to 2.4.22 to try out openmosix. It was absolutely annoyingly slow compared to 2.6.

Linux in cache?

[SHEENmaster]

What I'd like to see is Linux that could run entirely within cache on the higher end chips. Even dated UltraSparcII chips can have up to 8M/cache. That's 64M in an 8-way box, allowing for some truly awe-inspiring performance on mathematical problems if RAM is ignored.

I haven't looked into sparc assembly enough to know if this is possible.

Re:Linux in cache?

[ParisTG]

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 :).

Re:Linux in cache?

[runderwo]

Caching is controlled completely by the CPU, transparent of the programmer.

Only in some designs. Architectures like MIPS allow for both a cache-coherent or non-cache-coherent design. In a non-cache-coherent design, the cache is not transparent, and the kernel programmer is responsible for cache management; marking pages as dirty, flushing cache, etc. These designs are significantly more difficult to program and are present on some SGI machines, making porting to those machines a significant task.

Theoretically, higher performance can be achieved in a non-cache-coherent design, since the programmer would ostensibly know more about which data is most frequently used on his system and be able to customize his kernel for that. Also, it requires less glue logic on the board. However, the intent may be thwarted if the programmer doesn't have all the documentation (or skills) necessary to make efficient use of a software controlled cache.

Re:Linux in cache?

[lars_stefan_axelsson]

Caching is controlled completely by the CPU, transparent of the programmer.

Not really true these days. Some architectures do have an explicit 'cache preload' instruction, such as the SPARC V9 and the ARM9E to mention two. These allow the programmer to preload a D-cache line before it is needed.

As the speed of the CPU has increased much faster than the speed of main memory (and hence increasing the relative cost of a cache mis), compiler based techniques to emit cache preload instructions in advance, before the data is actually needed, has been the subject of some research in the past 7-8 years. The main reason to do it is software, instead of hardware, is that the compiler have a greater knowledge of the layout of the entire task, as it can 'look ahead' in the source code. The main disadvantage is that any static analysis, of course won't have access to dynamic (run time) data about the program as it is running.

If you wish to go further, you could do worse than to start with my former colleague Magnus Karlsson's PhD thesis on the subject:

Magnus Karlsson: "Data Prefetching Techniques Targeting Single and a Network of Processing Nodes". Ph. D. thesis, Department of Computer Engineering, Chalmers University of Technology, December 1999.

And of course as always, Google and citeseer is your friend.

In other words, just trust the CPU. It knows what it's doing :).

Well, actually, it doesn't these days... :-) Trust the compiler instead :-) (Yeah, right).

2.6 on server?

[black666]

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.

NTFS Read/write support?

[lawpoop]

The chart on the first page says that 2.6 supports read and write for NTFS. Is this really the case? Does anyone trust NTFS writing if it's in the kernel?

Re:NTFS Read/write support?

[jensend]

The native ntfs driver supports writing only if the write operation wouldn't disturb any of the metadata- that is, you can't create or delete any files but you can safely overwrite a file if you don't change its size. This is more useful than it sounds at first- you can use a loopback file on the ntfs partition for anything you want.

It's shame, really.

[Anonymous Coward]

It's not Linux 2.6.x, it's SCO/Linux 2.6.1.

Also notable....

[haggar]

..is the parformance of the Opteron. Looks like Linux 2.6.x and Opteron are a great combo. Okay, I admit, I was a bit skeptical regarding Linux 2.6, but it seems it might actually deliver.

I'm looking forward for Solaris + Opteron servers. Should be another interesting combo, performance wise. For one, Solaris 9 has some fantastic scheduling for multiprocessor machines. Additionally, it has been implemented in 64 bit for many years.

Re:Where's the distros

[MarcQuadra]

Wow, you need to quit bitching. 2.6 will be in the distros 'when they're ready', do you remember all the really broken 2.4.x stuff? It was REALLY bad press for folks who COULDN'T UNMOUNT DRIVES safely.

Let the ubernerds self-build 2.6 systems for a while and work out more bugs. If you want it you can have it, but mass-distribution before we even hit 2.6.2 might be a BIG mistake.

Re:My thoughts...

[pacman on prozac]

My thoughts were, wow, much faster. I'm now running 2.6 on all my desktop machines and it flies. They "seem" much more responsive with 2.6 than 2.4, especially under load.

The initial boot time to load the kernel seems to have massively dropped although I could be imagining that.

The new build system in 2.6 definately rocks, forgot to compile something important in? No need to wait for * to recompile anymore, just the vital parts are re-done.

Good to know that.

[nefele]

So if I use the new and improved herbal 2.6 kernel my processing power will be UP TO 150% BIGGER and my UPTIME will be 200% LONGER!!
And it's only $699 a box! ;-)

Time for some more FAIR benchmarks

[haruchai]

I'd like to see how Linux 2.6 stacks up against Windows Server 2003 now. This time, let's have Microsoft and Redhat or some other Linux gurus go head to head.
One of the good things of benchmarking at an early stage is that it may expose some hard to find weaknesses, much like the first Mindcraft tests exposed a kernel limitation which hampered Apache's performance.

Re:I can't believe these results

[JumboMessiah]

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.

backports

[POds]

for those who dont know, you've been able to get a back port of 2.6 on woody for the last month (almost).

so go get it, and tell me how it will effect my surfing, emailing, mp3ing and general userish behavour on my P2 400 128RAM...

Go on, get to it! :)

Re:backports

[shadowbearer]

I just compiled 2.6.1 for my 200mhz laptop (Debian unstable) and the speed increase - especially at boot and for Fluxbox - was very, very noticeable, particularly for cpu intensive apps.

I haven't noticed any breakage - not yet - the machine has only been up for 4 days running 2.6.1. But so far it's great :)

BTW I used the kernel source from debian, not the backport.

A question for anyone out there with a Digital HiNote 7xx series laptop; any idea which sound chip it uses, and how to set up sound? Google hasn't been very informative. (Not a 2.6 problem, I can't figure out which driver to use; most people seem to be using old SB compatibility, but I can't make it work :( TIA )

SB

Re:My thoughts...

[owlstead]

No, you aren't missing something. Applications will still run as they did, except when they are heavily multithreaded. Starting up something CPU-cycle expensive and typing in open office might give you an idea.

But all in all, it's the kernel. End users should be nicely unaware of it. Don't expect any fireworks to go off, most of the time you notice a kernel you will have hoped you didn't :).

Real world vs. fanboy fantasies

[Anonymous Coward]

I am what most people would consider a highly trained technical professional. Unlike most people who spout off at this site, I have the certificates to prove this, and furthermore they're issued by the biggest software company in existence.

I know how to tell facts from marketing fluff. Now, here are the facts as they're found by SEVERAL INDEPENDENT RESEARCH INSTITUTES:

Expenses for file-server workloads under Windows, compared to LinuxOS:

• Staffing expenses were 33.5% better.
  
• Training costs were 32.3% better.
  

They compared Microsofts IIS to the Linux 7.0 webserver. For Windows, the cost was only:

• $40.25 per megabit of throughput per second.
  
• $1.79 per peak request per second.
  

Application development and support costs for Windows compared to an opensores solution like J2EE:

• 28.2% less for large enterprises.
  
• 25.0% less for medium organizations.
  

A full Windows installation, compared to installing Linux, on an Enterprise Server boxen:

• Is nearly three hours faster.
  
• Requires 77% fewer steps.
  

Compared to the best known opensores webserver "Red Hat", Microsoft IIS:

• Has 276% better peak performance for static transactions.
  
• Has 63% better peak performance for dynamic content.
  

These are hard numbers and 100% FACTS! There are several more where these came from.

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???

--
Copyright (c) 2004 Mike Bouma, MCSE, MCDST, MS Office Specialist

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU
Free Documentation License".

Re:Real world vs. fanboy fantasies

[Cobron]

Sarcasm just goes WAY over your head, doesn't it?

This can mean two things...

[SharpFang]

Maybe one of them, maybe both...

1) The new kernel is really very good.

2) The old kernel is really very bad.

Really, if such huge increase was possible, there must have been a lot of room for it. If you face a really well written program, you have a hard time to speed it up by 5%. If you can speed it up by 50% without loss in other domains, it must have been seriously flawed.

Yeah, mod me flamebait. But first think if I'm really wrong.

Re:This can mean two things...

[iabervon]

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.

Naked eye test

[Zordas]

Yesterday I started a new Gentoo install with the 2.6.1 kernel. I used GCC 3.3.2 and glibc 2.3.2 with NPTL support. I have to admit, the naked eye can see a major diferance with the new kernel. With my XP computer and the new gentoo install (exact same computers .. P4 512MB) I ran a simple boot up and lanch a web browser test. And supprise supprise, Gnome is screamming fast. I had already booted and opened up mozilla 1.6 befor xp was even done booting! Also, simple stuff like opening up email, browsing, etc. is all noticable faster than XP. Soo... before I get slammed by the XP folks.. my XP box was also a clean install. (yes, I have no life!) I am happy to say I am one step closer to completely weening myself off of windows XP.

ahem...

[Apreche]

2.4 is the old and busted
2.6 is the new hotness

Re:Mystical Mozilla Speed Increases...

[Garg]

Sure, it's right there in the kernel:

if (strcmp(username,"ltorvalds")==0) {
gooseMozilla();
}

Garg

Re:My thoughts...

[shadowbearer]

Ditto here. I've been running the -test kernels on the faster machine since summer, so I can't remember just how much difference there was. I do know it was noticeable, tho. In particular setiathome used to noticeably slow the machine; now I don't even notice whether it's running or not. *grin* 2.6 definitely WU'ed me there *grin*

On the laptop I just compiled 2.6.1 for, however, (a 200mhz DEC HiNote) the speed increases are huge. You're not imagining the boot time drop - it's easily twice as fast on the laptop as 2.4.20 was. The GUI is also noticeably more responsive.

The new build system is great, especially on a slow machine :) Kudos to the kernel people, and thanks!

SB

Re:RPM for Fedora (Yum) ??

[inode_buddha]

ftp ://ftp.dc.aleron.net/pub/linux/fedora/linux/core/d evelopment

Re:RPM for Fedora (Yum) ??

[Anonymous Coward]

http://people.redhat.com/arjanv/2.6/readme.txt

Re:2.4 versus 2.6: file system performance?

[Debian Troll's Best]

Thanks for the suggestions hdparm, but since I posted my original comment my colleagues and I have decided on taking a hardware-oriented approach to solve our problem. Specifically, this will involve careful removal of the outer metal shell of each of the Seagate Cheetah SCSI hard drives from our RAID1+0 setup and making a few changes to the internal structure of the drive to effectively 'overclock' the hard drives. Let me explain

Stock Seagate Cheetahs use a fairly standard aluminium drive shaft, much like the one in a consumer grade piece of rubbish. We are replacing each of these with a carbon propeller shaft and light-weight fly wheel, which will increase initial acceleration of the drive platters, and will allow them to spin at a maximum speed of 17,500rpm versus the standard 10,000rpm. This should see our rate of apt-get transactions improve dramatically. But that's not all. As any good CPU overclocker knows, 'lapping' the contact surface of their heatsink will remove microscopic imperfections and result in a closer contact between heatsink and CPU. We too will be 'lapping' each hard drive platter. Of course this is dangerous to the platters, so we are always sure to use a fresh Kleenex each time. Once the platters are lapped, we can alter the suspension and damping characteristics of the read/write heads, making them float even closer to the platter and resulting in sportier turn-in, less body roll and more predictable handling even when dealing with 'rough' packages such as Troll Tech's Qt libraries which still have an aura of 'non-free' about them.

Finally we short-circuit resistor A24-J, which amazingly unlocks a special 'developers' mode of the hard drive, and firmware commands may be directly inputted using a text editor. We have developed a set of SCSI firmware routines which recognise the apt-get and .deb file formats even at the lowest level of hardware, offering stellar apt-get-goodness. Using a customised version of apt-get implemented in a mix of x86 assembler and Python (for the performance critical parts), apt-get is now able to bypass the Linux kernel, PC BIOS and the SCSI controller card, and communicate with the hard drive mechanics directly. This adds approximately an extra 60% to overall performance, to say nothing of the improvement in overall reliability and robustness.

We feel that these modifications will result in a drive array that will provide a superior platform for high-throughput enterprise level apt-get package management, regardless of filesystem. In fact we have very little choice about filesystem, since the lapping procedure with the Kleenex irreversibly etches tracks and sectors onto the drive surface. No need to worry about 5% of the drive being wasted on superuser-only space after a reformat! Now, I realise that these types of hardware mods may not be in the reach of all Debian users out there. I'm happy to discuss this further with the community if necessary. I am also creating a HOW-TO, which will be distributed via apt-get mirrors in the form of an 'info' document (man pages are filled with inaccuracies due to the inherently lossy compression techniques used in their production. RMS was really onto something with info!!!).

I look forward to the GNU/community's feedback.