Slashdot Mirror
Byte Benchmarks Various Linux Trees
urbanjunkie writes: "Moshe Bar has an interesting article, essentially benchmarking the standard kernel (with aa VM) against the -ac kernel (with Rik's VM)." He also raises some very interesting points about how patches (and entire development trees) interact.
Sorry for the dumb, offtopic questions.
I'm sitting at home with my fresh install of RH 7.1 and I'm wondering what kernel to upgrade it to. Any suggestions? Is there a stable one in there somewhere that I should go with? Should I stick with the default kernel that's on their now?
If I'm regularly compiling new programs using gcc or g++, is it safe to go from one tree to another, as long as they're all 2.4.x, or what? Do I need to recompile with a new kernel? Or is that a red herring?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Can anyone explain this? Was the stock 2.4.9 faster and more reliable than our current stable kernel? If there are stability and speed patches in the RH kernel, why haven't they been adopted in the standard kernel? How close is RHs 2.4.9 to Alan Cox's kernel? I'm assuming he has a strong influence on RHs kernel.
Correct me if IM wrong, but dont races in the kernel cuase horrible security problems?? And who would decide the race conditions?
In Soviet Russia you dant have to put up with these crappy jokes
2.4.9 was the last official kernel from linus which used Rik van Riel's VM which was introduced in 2.3.x. (The switch to Andrea Arcangelis VM occured in 2.4.9->2.4.10) Alan Cox and Red Hat used this in their kernels, and the Red Hat kernel was heavily patched with the patches from Rik van Riel which Linus "reportedly" dropped (among other things). The Red Hat kernel is also _very_ well tested, as all their kernels are. You might not like their distro, but their kernels are usually among the more stable.
One minor nitpick though ... I never released an -rmap VM against 2.4.18-pre3, the latest is still against 2.4.17. I suspect that the crashes Moshe saw are due to some change in 2.4.18-pre3 conflicting with the -rmap VM patch, especially since rmap-11c has survived the kernel torture lab at RH. ;)
Thanks to Alan Cox, Red Hat (and most Linux distributions) do have the patches for my VM that Linus didn't have the time for.
It is hard to believe that all this is going on with what is meant to be a stable kernel version, ie 2.4.x
So far the VM has been replaced twice, and now the rmap patch is apparently going to be added despite the fact that "something is seriously messed up in the reverse-map implementation".
Have they saved any experimental code for the 2.5.x kernels, or will that now be stable?
Interesting. I've not managed to run into bugs like that on my computers here, so you must be running a very different workload to trigger such a bug.
Would you have the time to help me debug this problem and is it still happening with the latest rmap VM ?
C'mon guys. Show a little open-mindedness. One of the things I really missed from the Windows world when I switched to Linux was the "Windows Update" feature. Want to install the latest security or feature patches? Click a check box and hit "install". No dependencies, no patch conflicts, no esoteric config options, it just worked. Admittedly Ximian's Red Carpet comes close, but it's still a little quirky sometimes.
I know there will always be those people who want to manually tweak their kernel (god bless 'em!). There's a lot of us, though, that don't want to deal with it. I'd rather have one-click shopping for all of my patch needs so that I can spend more time writing code or playing Quake. MS understands this. Apple understands this. Why doesn't the Linux community understand?
This
If you're using a fresh install, stop now.
You should use RH 7.2 instead. It comes with kernel 2.4.7 or something, but can (and should) be upgraded to RedHat's kernel 2.4.9 via up2date. The RedHat kernel is quite stable and fast.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
A major problem with alot of linux admins is shown in the article. It's not about how fast your kernel is, especially when it comes to a 2 second difference in 50 seconds of computing time, but how long your machine will stay up.
If a user compiles 35 gigs of code on a 6 processor box and it takes 5 minutes longer, he is not going to complain. If he compiles 35 gigs of code on a 6 processor box and it crashes half-way through the compile, your going to here it from your boss.
Benchmarking kernels is plain pointless. Take a machine for each kernel, put it under real load and tell me how many times it crashes in 100 days, and I will you which kernel I want to use.
Linux O Muerte!
I take your points about forking, but as a counter-example I'd think about the BSDs instead. They all operate under the same license, all forks from roughly the same code base.
The advantage here is that with three BSDs you have three separately-tuned operating systems that attack different problems very well, yet maintain a certain level of commonality and compatibility.
Call me a starry-eyed optimist, but my exposure to this open source fad started with the Wired article in the autumn of 1997. In it the writer painted a picture of a 'computing epic', one collectively started and maintained. I still think that metaphor is accurate and useful.
========================================
Death will come, and will have your eyes
-- Pavese
My -rmap VM is a patch against marcelo's standard 2.4 kernel, because that is the thing people have. It just doesn't make sense to release patches against kernels nobody has.
Also note that -rmap replaces pretty much all parts from the -aa VM I don't agree with, while at the same time integrating some parts from the -aa VM that I do like.
Under the section "Allocation and Swapping Results," I assume larger numbers are higher times and therefore worse. By the numbers, 2.4.18pre2aa (the Arcangeli kernel) seems to be the fastest overall, due to the 5th run (I would consider it the common case) results. Yet Moshe says:
"From the above figures it seems that the old van Riel VM is somewhat faster (considerably faster in the case of 2.4.9) than the new Arcangeli VM..."
Is my math wrong? The RVR VM in 2.4.9 is ever so slightly faster on the 2nd run and slower on the 5th, and the slowest of all is the newer one in 2.4.18pre3rmap. What's my mistake?
Moshe's politely indicating that van Riel was an ass when asked for comments; we can conclude either that Moshe didn't have a proper recent RMAP kernel to test with (as a result), or that the recent RMAP kernels are hit and miss.
From looking at van Riel's comments here, he vehemently believes his kernel is perfect and Moshe just got it wrong... The problem is that lots of people seem to "get it wrong" with that VM, including Linus... Overall in Rik I get the sense of an aggressive person who may have trouble admitting mistakes or accepting failure; not good traits in a programmer, since it's humility and communication skills which can often be the critical factors in a team programming effort... and lack of them can cause exactly the kinds of problems we've observed.
We're on the road to Tycho.
So how do you measure page faults? Be sure your kernel is configured with "BSD process accounting". Then use a shell like tcsh. The man page of tcsh describes the "time" variable, you can set it to report the number of major/minor page faults that occured during the lifetime of the process.
I did my own unscientific test back in November. I ran 32 simultaneous instances of mpg123 on a just-booted machine. Among other things I measured the number of page faults. The results for the then-current kernels I had were:
those number are the means of the 32 values from each process. Anyway, you get the idea.
Yes, I post the link to this here all the time, I think it's useful to people.
-- Could you use my software consulting serv
Wow! Reading this story at +5 is like seeing Rik van Riel have a conversation with himself!
"The scientist describes what is; The engineer creates what never was." - Theodore von Karman