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.
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.
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.
(and personally, I'd prefer to keep -rmap separate for quite a while more ... development is much more efficient in a fork)
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.
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.
I think that's easy to understand. Since all paging algorithms basically use some LRU strategy (least recently used, the pages which aren't used the longest time get swapped out), what happens is that you will never find a page already in memory. The memory you're going to access will always be just swapped out.
Probably no vm is going to change this, since it's impossible to know what pages you're going to access in the future. It's up to you to change your algorithm so it doesn't operate sequentially on all the memory (called "blocking algorithms" IIRC).
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
Hmmm, I sure wish I had a system that could swap out over 400meg/sec. I want his 18gig HD's! 200meg/sec to each of them!
Just checked the source, vmstat doesn't normalize based upon how long it really took. Without time stamp information on each line of the vmstat, the swapping rate is not reliable. Almost all OS's have this problem. You aren't suppose to do benchmarking with vmstat.
John-Mark Gurney
Walking repeatedly and sequentially over All Memory + K tends to result in worse case performance. The reason is that when you hit the +K at the end of the loop you page out the oldest memory, which is the K at the beginning of the sequence. When you restart at the beginning you need to get this back in, so it pages out the next oldest K, which is of course the next part of the sequence. Thus you end up paging in and out the whole 1GB on each iteration, resulting in a massive slowdown.
(The real answer is less simplistic, but this is close enough to the truth.)