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%

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

Re:My thoughts...

[echeslack]

I don't notice any real speedups, but I do not really notice updatedb running anymore. Actually that's not entirely true, I just notice it a lot less. Many times it will run and I won't notice it. The mouse used to start getting all sticky when I had too much disk activity. Now it *mostly* runs smoothly.

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

Benchmark against vendor kernels?

[salimma]

No self-respecting large Linux distributor would ship a vanilla 2.4 kernel (well, SuSE does, but as an option, and not pre-compiled). The O(1) scheduler which AFAICT makes quite a large performance difference, has been available since RH9, IIRC, and presumably its contemporaries adopted it back then as well.

So it's not such a big leap for real users. Mind you, still a big improvement - especially for interactive use, and also considering that there are so many patches for 2.4 that are now integrated into 2.6, lessening compatibility worries (try patching Red Hat's pre-FC1 2.4 kernel source).

Re:Who cares? OS X kicks both.

[be-fan]

Actually the OS X kernel is about half as fast in lmbench (UNIX benchmark) as Linux 2.4. The OS X kernel is really antiquated. Much of it is 4.4BSD and Mach code. The GUI is modern, but the guts are ancient.

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

did I hear JOKE?

[tasinet]

i dont know if it's been posted already but check this. Aint no joke mister.

Re:Also notable....

[paitre]

Sun is doing an Opteron-optimized build of Solaris, but don't expect it in the short term.
That's about all I can say ATM, but it -is- on the way...

Re:How does this compare to the BSDs?

[tarm]

Try this link.

It's an excellent comparison.

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

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

Re:Requirements?

[The One KEA]

Check the Changes file in the kernel source. Basically any modern distro like Fedora Core 1, Mandrake 9.2, SuSE 9, Gentoo, Debian-unstable or whatever can all compile and boot 2.6 kernels without any real problems.