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.
While I personally may not have agreed with this synopsis prior to reading the article (and am still not completely sold...), there are certainly some interesting facts and figures to ponder the next time you reload your system or update your kernel...
Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin
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.
He's still writing - good classic Science Fiction, and still writing Chaos Manor, his collumn for Byte. He's also got a site that is similar to Slashdot in "umm... vaguely geeky stuff, lots of visitor feedback and opinionated as hell". It is located (in all its hellishly difficult to navigate, 'spend a few hours finding the good stuff buried deeply' glory) here.
--
Evan "Many many years spent with Byte" E.
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
The rmap patch is nice.....
.....
It makes a big difference on loading the hell out of my woefully under memoried workstation at work. My home machine, used mostly for surfing has seen a dramatic imporvment in free memory and is no longer swappin , it has 512 meg, so it really shouldnt swap too much, but was constantly with the stock redhat kernel, as well as 2.4.17 plain vanilla, trhe 2.4.18 -rpma12a has been ROCK solid.
On my server however with 256 megs , the stock redhat roll has done nicley with the minimal load its under.
I am a little leary about using the rmap in prouction as of yet, it seems to be killing things each nigh, (no shit) that dont drop with 2.4.17 or 2.4.9
I would like to see an option at configure to select a VM, I think the preemptive added would be fun too, I know its a pain because of the way it all intergrates to the other code, but thats my desire, it seems to be alot of other peoples desire as well, its funny how I bitched and moaned about the Riel VM , that was in the kernel prior to AA's , but since then and all the patching that was done I think Riels would give it a run for its money
Sig went tro...aahemmm.....fishing........
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.
If you have RedHat use up2date, with Debian use apt-get.
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.
Pournelle is a science fiction writer and also a computer columnist for Byte magazine (byte.com now). I think his original degree was in political science (!) but somewhere he learned quite a lot about engineering, and he did the original (DOS/BASIC) programming for his wife's learning to read program. I assume his computer skills are self-taught -- he's got to be at least 60 and there were no programming classes when he was young. He wrote political columns for Intellectual Capital a few years ago, when that website was worth looking at. In the 60's he was something in NASA management -- and also he appeared at least once on national TV in a debate about the Vietnam War.
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?
There was no stock 2.4.9 in the test; only RedHat's highly modified 2.4.9.
RH 2.4.9 is a lot like the ac kernels. Mainly because, Alan runs that part of the RH distro. But, there are many concerns that RedHat addresses. They work with corperate customers and partners (like Oracle) to make sure the kernel they ship is as stable and fast as they can get it. So the RH kernel does diverge from the "plain" AC kernel.
Of course they submit all their patches back to Linus. But Linus just hasn't been keeping up with them. Linux accepts patches based on three factors: his previous experience with the developer submitting the patch, the "correctness" of the patch, and the phase of the moon. And the phase of the moon is the dominant factor, because even Alan Cox complains that Linus won't accept his patches.
So the RH kernel is excellent because Alan Cox, RedHat, and RedHat's corperate partners make sure the kernel is fully fleshed out. This is the kind of vetting that Linus doesn't do.
"If it compiles it is Good, if it boots it is Perfect!" -Linus Torvals.
-- I am not a fanatic, I am a true believer.
There are various patches like the Robert Love's preempt patch which might be considered production quality. And perhaps some collections of production quality patches exist out there. But I wouldn't say -ac or -dj are in that category.
Or any of the patches marked 'preXYZ'. They're 'pre' for a reason you know. I'd be thrashing them on test servers, then giving feedback to the maintainer of that series. Let the maintainer declare them stable first.
You'll find in environments ambivalent to Linux that you really need to prove its stability to management first. Trying a new whiz bang kernel can have unforeseen side effects, in meetings that you'll never be invited to; and whose outcome you will only learn when it's too late to change it. "We let Bill convert server X to Linux and then it corrupted the filesystem. Clearly Linux carries more business risk than expected."
Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
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.
I'll probably get flamed for this - but I installed 2.4.17 from Red Hat's Rawhide distro (find it on rmpfind.net) and it worked like a champ.
rpm -Uvh kernel-2.4.17-athlon.rpm or whatever it was and rebooted. I'm sure everyone will chime in on how 'evil' it is to install a kernel by rpm, but for my typical desktop box, it's no big deal.
I think you'd need to get the new modutils package, but i don't recall.
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 think Rik's discovered a good new way to karma-whore.
/.
1. Write a VM.
2. Get a fine article written about your work
3. Have somebody post the article on
4. Post. Post. Post.
Rik's put in at least 3 comments in this tree and they're all being mod'ed up.
I'd better start on my own VM!
(Or, I'll write a reverse disk-sector mapper)
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
I don't think this is a bad thing, really. People have conflicted ideas so two forks form. Each fork is evaluated in the eyes of the hardcore users and in the eyes of distributors such as RedHat. Sure, we look now and think that things will get ugly as all these trees evolve, but as the past has shown, the trees that work better, or are closer to the pre-exsiting "standard" given a tie, dominate and often extinguishes less succeful trees whose ideas didn't pan out, usually folding in the improvements the other tree made succcessful.
The process of having these trees sprout up and played with by businesses and advanced users provide a sort of natural selection for improved evolution of the system. While all this complicated mess plays itself out among the bleeding edge people, the common users have the stock redhat or what have you kernel to play it safe with.
XML is like violence. If it doesn't solve the problem, use more.
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.
The current kernel supported by Red Hat for Red Hat Linux 7.1 is 2.4.9-21, which you can see does a good job in this test.
Can you provide some high profile forking examples that have occured in the recent history of Open Source, out of interest? Or evidence of similar forks in Linux. Not, to coin a phrase(?), "soft forks" as I have mentioned here, but "hard forks". Fundemental changes in ideology or personality clashes that have seriously caused a split in the community?
Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
It's good to see that Slashdot users still don't use computers for anything... I'm not looking for a system with better uptime than Win95, and that seems to be all you guys want.
I can't have multiple crashes in 100 days. If you are doing real load, spend real money, get real systems.
Don't build machines with your screw driver, get QA'd servers. Don't roll your own kernel, let Redhat test it.
These types of tests are useful as commentary and recommendations for what people should do in the development process.
Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
Since I've seen posts from at least one kernel developer in response to the attached story, I figured that this might be a good place to ask the following question:
A little while ago, I wrote an application that uses an incredible amount of memory... A very space inefficient implementation of Eratosthenes' Sieve. In essence, what the algorithm does is cycle through the entire contents of memory sequentially many, many times (not a completely correct description). What I found with the following three kernel versions:
- 2.4.4
- 2.4.8
- 2.4.17
is that any time the program's footprint exceeded the physical ammount of available memory, performance degraded exponentially. I found this to be very suprising, considering that I was only exceeding the physical 1024 Megs of memory by less than 10 Megs. About the only difference between the three kernels I listed above is that the 2.4.17 kernel would kill of memory intensive processes a lot quicker than the other 2 versions.My question for the Kernel gods out there is as follows: are there any stable 2.4.x kernel releases out there that would handle this type of stress without the performance degradation that I've experienced with these kernels?
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.
I'm using FreeBSD as a desktop OS at home and as a workstation at work. It's simply great!
There are only two advantages I see to Linux that makes it a better "desktop" OS. First, they put DRI in the kernel. They're working on this now for FreeBSD, but there's a lot of resistance to keep userland stuff out of kernelland. If all you care about is running games, then FreeBSD is not it. Go get a PS2 or an XBox.
Second, the popularity of Linux gives it a greater pool of developers to draw from. So Linux gets new device drivers faster. But you still will *not* get Linux shoehorned into this week's premium super buy at CompUSA. With Linux you have to wait around three months to get a driver for brand new hardware. With FreeBSD you have to wait about six months. If you buy computers more often than once every six months, stick with Linux. As for myself, I had no problems with FreeBSD on a stock Dell Optiplex GX240.
In terms of desktop software, don't worry a bit about it. They're the same on both platforms. Identical. Staroffice, GNOME, KDE, Xmms, Gimp, Mozilla, etc.
A Government Is a Body of People, Usually Notably Ungoverned
This is not a flame, am really just curious...
:-D..?
I compiled and ran the "memory hogger" application
and it did not eat more than 424K on FreeBSD..
I know you have a lot more to do thatn to answer silly simple questions BUT.. why is that
Thx in advance..
There's a big problem in your argument. You assume that when someone "buys a new system" they are getting all of the very newest hardware.
I venture to say I am not alone, in that when I upgrade, I always upgraded to hardware that was already out at least 6 months anyway (even when I ran windows), that is where the sweet spot is in price/performance ratio usually.
So, one could buy a new system every 6 months, with no driver hassles at all, if they just trail the market, like I'm sure millions do. (at least everyone who isn't rich and wants the most for their money).
I've had enough abrasive sigs. Kittens are cute and fuzzy.
All Rob was suggesting was a formalisation of a de facto practise. Hardly a fundamental paradigm shift in kernel development.
It did unearth a number of gripes people had; eg. Linus dropping maintainer patches. The thrust seems to be that Linus wants to trust ten or so people, and only accept patches from them. So if Linus is dropping your patches, push them on to a 'trusted' maintainer instead.
IMHO Linus needs to step forward and deal with this a little more assertively. But everyone loves a good bit of controversy, and the Linux kernel is the tall poppy of the open-source community that everyone wants to chop down ...
Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
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.
Why would I want to play Quake at a measily 60 fps for 2 years straight, when I can play it for at most 1 hour at a blazing 61 fps? :)
If you see a Linux kernel crash, it is either hardware failure or a kernel failure. Since hardware failures (especially RAM and power supply) can be imposssible to repeat, the only way to prove that it is a kernel failure is to find the kernel bug. If you find the kernel bug, then the bug gets fixed, and suddenly your crash data is for an obsolete kernel.
You could try to take a statistical run at it, of course, but I suspect the number of machines required to give meaningful results would be on the order of Google's farm.
If everything goes according well, your kernel should swap out and swap in exactly M amount of memory for each preaccesing pass, where M is the amount of data that does not fit in the main memory. So if you have total memory T, total data T+M and K*J size prefetch, total swapped data per whole process would be M*(T+M)/(K*J).
Gentlemen, you can't fight in here, this is the War Room!
Is there any telling what patches are used in the Red Hat kernel releases? Or is that a trade secret? I know the source is there, but when you start talking about multiple patches, it seems like it would be a tough one to figure out.
It seems like this may be the key source of competitive advantage for a Linux distribution vendor: the know-how to optimize the kernel and other software to make a fast, stable system.
Now, the bigger question is.. why would linux's vm allocate empty pages?
The raw performance of the VM is certainly important and all, but what I'd like to see are some *application* benchmarks among the various kernel trees. Star Office, the window managers, KDE, GNOME, etc. Graphics. Storage. Networking. Unles we're talking heavy metal servers running the usual suspect daemons the average user doesn't really give a hoot if the VM is well-designed or not - only if The Gimp runs quickly enough.
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
In the context of evolution Torvalds represents natural selection, and kernel developers changing the code represent mutation, albeit a poor representation because the developers have some sense and purpose in what they do, while mutation "in nature" has absolutely none.
I have to disagree with the notion that this isn't Exactly how evolution occurs. Evolution isn't Random, Virus are the vector for almost all radical natural genetic manipulation. The purpouse of a virus is to use the resources of a host organism to replicate it's DNA sequences because Virus are too small to replicate themselves. In doing so It injects it's DNA inside a host cell and basically exploits the RNA strands inside to replicate it's own DNA. While doing this The virus can in fanct find new DNA within the host and borrow it for it's own protection. In many cases this is to make it resistant to antibodies produced by the body (HIV.) Now, not all Virus destroy the host cell especially when antibodies destroy it before it can complete it's task. In some instances the Virus may act as a Vecor Borrowing the DNA from one species, and inserting that code in another. Many virus can cross infect species. For example humans and pigs can catch influenza from each other. Geese and pigs can also catch influenza from each other, while humans and geese cannot infect each other with influenza.
Virus are acting for thier own self promotion and preservation. When a DNA stand from one species makes that species less able to destroy them they would try to splice that DNA into as many species as they can. Comparing that to kernel developers
is pretty straight forward. They try to 'infect' the kernel tree with the 'code' they've produced for any number of reasons. Being known for coding on linux, to get promotions at a linux friendly workplace, for the challenge and fun of contributing to the linux kernel, or just to fix something so that they can do something with linux that they were trying to do but couldn't.
This introduces variation along the same analog as virus changed DNA. As for 'uncorrected errors' in the DNA strand the only thing we can prove comes from that is cancer. Thus that type of 'mutation' is analog to 'bugs' in the code of the linux kernel. Unfortunately humans aren't anywhere near as good as the roughly 99.7% error correction rate of replicating double helix DNA strands, so code tends to get a lot more malignant tumors (root exploits) to cut out.
https://www.gnu.org/philosophy/free-sw.html
it seems that the vast majority of commentary here all assumes that a linux machine is run as a server, or at best, some kind of generic desktop machine. while linux may be very good at running servers, and may be capable of acting as a good generic desktop machine, some of us are interested in it for much more specific tasks such as realtime audio processing, editing, synthesis and recording. we care about those extra 2 seconds spent in the VM code during a benchmark. we care about all the extra paging that goes on with some designs. we care about the internal operation of the buffer cache and how it affects attainable peak i/o performance because we stream, and when i say stream, i'm not talking about measly HTTP numbers, i'm talking about 64-128 streams of 24 or 32 bit 96khZ audio data. stop assuming that a top-end linux box is a server, please.
The linux-2.4.17 kernel rocks the world. I have had not a single problem since compiling and installing it AND I've also had more things begin working.
Before 2.4.17, I couldn't get sound to work with Return to Castle Wolfenstein... trying to run the game with sound would just put the machine into a probable race state... I'd try to run a program and it would just hang... switch to another virt term login run top and hang...
I'd have to restart the machine because I couldn't even kill the processes. But with 2.4.17, NO MORE PROBLEMS.
Me is a happy camper.
Codifex Maximus ~ In search of... a shorter sig.
Keeping the realtime code in the main code tree would be counter productive -- confusing the development of the larger Linux tree, but not providing much of anything to the 98% of us who have little need for hard realtime in our systems.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
I'm going to disagree with this notion of evolution. Evolution is not undirected. The current environment gives a good deal of direction to the sorts of evolution that occurs. For example: evolution appropriate to tropical beaches is unlikely to occur in the arctic tundra.
Similarly, Evolution in the Linux world is also mostly in reaction to environmental needs. Where the difference in randomness comes is that the mutations that lead to biological evolution are generally random in nature -- but environment and statistics choose which mutations lead to enhanced viability.
For Linux, patches are generally in direct response to specific needs. The nature of these changes are directed by nature but generally random in form -- ranging from the icky to the elegant. Fork maintainers like Torvalds and Cox are more like the social interactions which can shift the survivability of an otherwise brilliant mutation/patch. Although this social rejectin will deeply affect survivability, an especially bright change can still give a survivabillity edge that makes up for the rejection
This is really the pleasant aspect of the Linux community; exactly those people who are busy and sought after by many journalists and hackers are also those who take time to answer questions with enthusiasm and a very positive attitude. Thank you Andrea, thank you Alan.
This is something of a chicken and egg proposition. Those people "who take time to answer questions with enthusiasm and a very positive attitude" are precisely those who will likely be sought out by Journalists and others. I mean -- come on! Are you going to take your question to someone who regularly beats into submission anybody who comes to them with (what they consider) a non-profound queston?
Journalists, especially often need their question answered today , and can't be bothered to wait for someone who berates them for half an hour for asking a straightforward question -- especially if they then forget what the origina question was (no known anectdote comes to my mind).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
"Too much work at interrupt"?
Switch to netgear cards / ng_tulip driver. I've never tried to gauge them for performance, but at least the driver is solid.
I don't know you guys, but my all-time favorite benchmark tool is Seti@Home. =) The distro which spits out more work units, that's what I'll take. And my linux box does 5 times as fast as my w32, mind you. But you already knew that, did you? =)
You don't happen to run commandline client on Linux and the 'gui' client on Windows, do you? ;) The difference between gui and commandline client is huge on both Windows and Linux.
Everyone who makes generalizations should be shot.
Evolution is directed by the needs generated by (or arising from) the immediate environment.
and -- yes, I agree. The earth and nature have no needs, per se. As an environmentalist, I would say that we have needs, and if we sate our needs and desires in a way inconsistent with what Mother nature 'needs' (i.e. what would be required for it to stay stable and supportive of thriving human life), we're going to pay bigtime, in the future.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.