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.

Comments

Re:Red Hat 2.4.9 is a very good kernel, fast...WHY

[keeg]

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.

Re:Stable kernel?

[Rik van Riel]

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

Ummmm, -rmap is still under development. If there are any plans to put it into 2.4.x, people sure haven't told me about them. ;)))

(and personally, I'd prefer to keep -rmap separate for quite a while more ... development is much more efficient in a fork)

Re:[ot] So what's the best kernel to get right now

[JediTrainer]

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.

Re:If you support forks so much...

[Rik van Riel]

Nice troll ... ;)

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.

why didn't author measure page faults?

[brer_rabbit]

I've asked this before when people do benchmarks and I'll post it again: why don't these authors measure page faults? Measuring the total time the process runs is good, but if you can measure how many page faults occured you'd be providing a lot more infomation.

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:

kernel: 2.2.20 2.4.8 2.4.12
mean elapsed time: 88.6 86.5 88.4
mean page faults: 7833 7285 8990

those number are the means of the 32 values from each process. Anyway, you get the idea.

Kernel Test Suites Article

[goingware]

Some of the test suites in Using Test Suites to Validate the Linux Kernel might be good for benchmarking.

Yes, I post the link to this here all the time, I think it's useful to people.