Ensuring That 2.6 Will Perform Better Than 2.4

Jeremy Andrews writes "Con Kolivas, a practicing doctor in Australia, has written a benchmarking tool called ConTest which has proven to be tremendously useful to kernel developers, having been designed to compare the performance of different versions of the Linux kernel. In this interview on KernelTrap he explains the project, noting that "a good 2.5 kernel (and that's not all of them) feels faster than 2.4 in most ways and this bodes well for 2.6." Also discussed is his high performance -ck patchsets, adding performance to the 2.4 stable kernel with the O(1) scheduler, kernel preemption, low latency, compressed caching and more..."

Comments

Beta testing 2.5!

[Blkdeath]

I certainly hope 2.6 out-performs 2.4, I mean, who'd want to take a step backwards, right? But we have a problem - the kernel team are implementing lots of top-notch functionality, but don't have enough people testing it. There are still compilation failures, ACPI buglets, and small quirks with several other sub-systems (speaking from my own experience here). Linus pleaded to the LKML not so long ago that he hopes lots more people will start plugging away so they can find and fix all the kinks before we go to 2.6 (or 3.0, like, whatever. :) ).

So download away and start testing!

Re:Beta testing 2.5!

[Blkdeath]

Which brings up the key question... What are the other system requirements for running the 2.5 kernel?

Present system requirememnts are still listed in Documentation/Changes (referenced in the README file, which of course everyone reads before they attempt to compile a kernel, right?) and go as follows;

o Gnu C 2.95.3
o Gnu make 3.78
o binutils 2.9.5.0.25
o util-linux 2.10o
o modutils 2.4.2
o e2fsprogs 1.29
o jfsutils 1.0.14
o reiserfsprogs 3.6.3
o xfsprogs 2.1.0
o pcmcia-cs 3.1.21
o PPP 2.4.0
o isdn4k-utils 3.1pre1
o procps 2.0.9

I couldn't post a direct copy/paste from the file, because apparently it contained too many "junk" characters and wouldn't pass the lameness filter. But if you download 2.5.43, you could just open up the file yourself. :)

I wait anxiously to test the new(er) 2.5 kernel; 2.5.39 compiled and runs for me, but I get a mini-oops on startup (haven't had time to report it yet. :/ ). 2.5.40 wouldn't compile, I missed .41, .42 had a flurry of "WAIT! IT'S STILL BROKEN!" messages on LKML, and I have yet to grab .43 at home (I've got it at work, which does me no good at home, see. :) ).

As soon as I get a chance, I intend to start hammering at 2.5.43 and file a bug report for any anomale I see.

Re:Beta testing 2.5!

[Blkdeath]

No response whatsoever. I guess they don't want to hear that there are actually bugs in their shiny new kernel.

Perhaps you just gave them enough information that they didn't need anything further from you, and instead went hunting for the cause of your problems. Speaking as a former programmer myself, often times I wouldn't consult directly with the user(s) who submitted bug reports, but would instead fix the problems and ship out a new, more stable version.

Aside from that after tweaking I got it to work, and it did outperform 2.4.18 in everything we cared about.

Excellent! I hope you've posted a follow-up to your initial message to LKML so people will know the solution as well as the problem.

Cooperation for a better OS, etc.. ;)

Re:Beta testing 2.5!

[Blkdeath]

Hell, without improved USB and journalling filesystems, what was the point in 2.4?

The new VM was one of the big kickers (then they replaced it mid-stream with a better one, which was risky at best, but I digress). I've found that on all workstations and servers on which I've installed the 2.4 kernels performance is through the roof. It responds faster under all load conditions than any 2.2 kernel ever could.

I read the kt digest, but I'm really not seeing any new wonderful things. Perhaps there are others in a similar situation?

Pre-emption, new I/O scheduler, new paging, all sorts of wonderful stuff that makes the kernel more suitable for heavier loads. Most everyone who's tested it thus far sees it performing far better than 2.4 so far, and it's got a whole slew of improvements yet to come.

There's also talk of replacing LVM1 with LVM2, and supporting various other logical disk managers which will make it more desireable on the enterprise front.

Re:Beta testing 2.5!

[Blkdeath]

I'm a geek type with a little(very little) experience programming, and I'm competent with linux... what/how exactly could I help beta test a kernel? what does it entail? I'm guessing it's more than just compiling it on my system and going "ok, it worked!" Perhaps someone can give me some pointers so "people like me" can help too.

Compile the kernel, boot the kernel, report what breaks. If something either breaks or significantly slows down (performance loss), report it with great details to the appropriate places.

See the file REPORTING-BUGS in the Linux kernel source directory for more information.

compressed caching......

[oliverthered]

"compressed caching offers nothing to machines with heaps of ram",
If memory transfer and access speed is causing a bottleneck then well designed compressed caching can give a good performance increase by decompressing into the cpu cache.

Streems with small blocks would probably give the best performance increases.

Re:compressed caching......

[Hast]

Regarding SMP the interview state that the compressed caching isn't compatible with SMP. (At least not now. No details are given.)

And regarding network protocols: It depends on which level you are building. On the application level a simple and slightly verbose protocol is nice from a debugging and future safe perspective. (Think HTTP.) When designing protocols for the link level it's not as much use though. (Most likely you'll just simulate that in any case. "Hot debugging" isn't all that much fun there.)

Re:a good 2.5 kernel?

[Charlton Heston]

The answer is yes, some versions of the kernel are better than others. But these differences are sometime subtle. As a newbie, your biggest concerns are probably does it run my programs, and does it stay running without crashing. Beyond that you can satisfy your curiosity to get the details. Read the kernel development mailing list archives. Read the kernel source. There's about a zillion different patches that people have written that aren't in the kernel. You can find them and try them out on your own kernel. Take notes, and maybe build a webpage with what you learn.

Re:a good 2.5 kernel?

[cartographer]

The 2.5.x set of kernels is the development branch (the key being the odd minor number). It's where major feature changes are taking place, and new ideas are tried out. As you'd expect, things don't always work at the first (or fifth) go, so not every 2.5.x kernel is going to be 'good'.

'Good' probably depends a whole lot on how well the bits you need for your exact machine configuration are currently working, so your good kernel may be someone elses nightmare.

The lesson to all this is 'don't use a development kernel if your not ready for breakage'. That means back up all your file systems and don't even think of putting one on a production machine. But if you have some new widget that isn't supported in the stable kernel series (2.4.x currently), you might want to see how the development series is shaping up and even offer some feedback so that the next stable series really is.

Re:a good 2.5 kernel?

[Anonymous Coward]

Linux Kernels are like Star Trek Movies. The even numbered ones are always the best (2.0.x, 2.2.x, 2.4.x). The odd numbered ones are a bit unstable and are really made for development purposes. However if you don't mind testing and reporting bugs, feel free the try the odd-numbered sub-versions.