If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The Performance Of Fedora Core 3 Through Fedora 14

11-28-2010, 08:20 AM

Phoronix: The Performance Of Fedora Core 3 Through Fedora 14

Recently we published benchmarks of Debian with the Etch, Lenny, and Squeeze releases. This is as far back as we could benchmark before hitting the 2.4 Linux kernel and running into hardware compatibility issues and other problems, considering Debian GNU/Linux doesn't seen an official release nearly as often as Ubuntu, Fedora, or most other distributions. We have now carried out a similar process, but on the Fedora side, and here we were able to go all the way back to the 2004 release of Fedora Core 3. Here are benchmarks of Fedora Core 3 with every release up through the recent release of Fedora 14.

Comment

"Fedora Core 4 having done surprisingly well with the GnuPG benchmark"

I smell something weird here. The result is too good.

Nah -- something in the kernel (or userspace, since we're testing entire distros here) got optimized in FC4, but then they realized that the optimization was either dangerous or had correctness/safety consequences. Either that, or something like filesystem caching logic got changed significantly in FC4 and then reverted back to the old way with FC5 and later. Of course, this is all speculation -- but nothing a good bisect can't isolate if you are really interested. Although I'm not sure if there are git commits for kernels going that far back...? Didn't they use BitKeeper or something before?

If the result were just statistical error or host-side side effects (since it's in a VM), you would see more results skewed, and the standard deviation would be much higher than it really is. So I think it really was better.

These are very interesting results overall. IMHO this long-term analysis is much more revealing of performance trends than the usual myopic 2-3 release measurements. Sometimes, regressions are a sign that some subsystem is under major upheaval, and the new paths just need to get optimized and better tested, which we see happening a lot between F10 and F14, with the "dipper" effect: regression, then it comes back. The mostly-userspace, CPU-bound stuff is naturally going to be pretty flat, but anything involving a lot of syscalls seems to have changed a lot because of these cycles of evolution (mainly in the kernel) over the past few years.

Comment

Can we expect kernel devs go back and look at the chart, and, say hmm, some Fedora version perform significantly better in some tests than current kernel, and they would fix the regressions in current git kernel so we would get the best performance ever.

These results should be submitted to lkml.org or something.

Comment

Can we expect kernel devs go back and look at the chart, and, say hmm, some Fedora version perform significantly better in some tests than current kernel, and they would fix the regressions in current git kernel so we would get the best performance ever.

These results should be submitted to lkml.org or something.

I think the tests should be re-run with the filesystem mounted with nobarrier. That would make it clear what is a regression and what is not.

Comment

There exists data w.r.t. Kernel results over different versions.
Wouldn't have made more sense todo a kind of gain plot by referencing against the kernel version that that particular Fedora shipped with

That way it would remove any regression/boost due to the kernel alone

Comment

Can we expect kernel devs go back and look at the chart, and, say hmm, some Fedora version perform significantly better in some tests than current kernel, and they would fix the regressions in current git kernel so we would get the best performance ever.