Linux Kernel Benchmarks, 2.6.24-2.6.29 38
Ashmash writes "Phoronix has posted benchmarks of the Linux kernel from versions 2.6.24 to 2.6.29. They ran a number of desktop benchmarks from the Phoronix Test Suite on each of the six kernels on an Ubuntu host with an Intel Core 2 processor. The points they make with the new Linux 2.6.29 kernel are 1. there's a regression with 7-Zip compression 2. OpenSSL has improved significantly 3. a regression drastically impacting the SQLite performance has been fixed 4. the OpenMP GraphicsMagick performance is phenomenally better with this new kernel. In all of their other tests, the kernel performance was the roughly the same."
Re:Why no comparison to OS X? (Score:5, Insightful)
Re: (Score:3, Informative)
Besides, how do you expect a different binary to be fair? At least in this test the only variable was the kernel, whereas on OSX you have the kernel, application specific code, and the compiler to consider. They can't exactly copy the ELF binaries and libraries straight over from Linux.
Re: (Score:2)
They can't exactly copy the ELF binaries and libraries straight over from Linux
They can to *BSD or Solaris though, and that would make for an interesting comparison. Last time I saw anyone do this was a few years ago, and FreeBSD was around 5-10% faster running Linux binaries than Linux was, although I wouldn't be surprised if this has changed now.
Re: (Score:2)
FreeBSD was around 5-10% faster running Linux binaries than Linux was, although I wouldn't be surprised if this has changed now.
I would, actually. If history [slashdot.org] is any indication, the operating system gets slower as time goes on. Note that I actually have oprofiled some of these areas, and it's frequently due to things like processor ACPI enablement (processor sleeping) and security improvements like stack randomization.
The OpenSSL benchmark (Score:2, Interesting)
I find it difficult to believe that the 2x gain in OpenSSL performance for 4K RSA private key operations is solely due to this new kernel. Such operations are, at the core, just CPU-intensive modular exponentiations. Unless the kernel has become significantly better at making use of several cores (or processors) to parallelize such operations, I don't see how that can happen.
Re:The OpenSSL benchmark (Score:4, Interesting)
There are lots of variables that may affect this. The new kernel may be preempting the CPU-intensive process less frequently, reducing TLB and cache churn, and context switching overhead. I don't think RSA should be using the FPU, but if it is (even for one operation in the 10ms quantum) then switching to lazy FPU context switching would give a performance increase (or, to put it another way, not doing lazy FPU context switching - either by accident or design - would give a performance penalty).
I didn't read TFA (obviously), but on an SMP system, particularly an AMD machine, there are a few other issues that may arise. Without good processor affinity, the OpenSSL process may be being swapped between two cores, increasing cache misses (which can easily slow down a process a lot). The memory allocation routines may have been allocating memory from the memory controller attached to one processor while running the code on the other, increasing memory latency (and, therefore, cache miss cost).
In short, there's nothing a kernel can do to speed up CPU-bound operations, but there is a lot it can do to slow them down, and stopping doing things that slow down operations looks a lot like doing things that speed them up.
Re: (Score:2)
Yeah, as you point out, some benchmarks on phoronix have been pretty sloppy.
I think it's a great site for some purposes (where else can you find headlines on X development?), but I doubt many take their benchmarking seriously.
While bad benchmarking is hardly rare, it's kind of disappointing in the case of phoronix, which is obviously aiming at a more technically savvy audience than most sites are, and often does benchmarks (such as this one) that are much more interesting to the FOSS crowd than the typica
benchmark snd-hda-intel sound recording too! (Score:3, Interesting)
Why dang it? (Score:5, Interesting)
Neat. They benchmarked a bunch of stuff and some real changes obviously took place. I can't help but be comforted by their conclusion (paraphrased): "Stuff changed."
How about telling me why they changed.
Why did SQLite performance bomb for 3 releases?
There are reasons for these things. You could test and find them out. You could read the mailing lists and see if someone else posted explanations (others must have noticed the SQLite thing).
Heck, look at this list of new features and make guesses. I'd prefer "the newly added HyperScheduler v3.732 is probably the source of this" than the article's "things got faster, neat."
That's why I love LWN [lwn.net] and the kernel page so much. They post why things changed, or at least reasonable theories.
Re:Why dang it? (Score:5, Insightful)
I'd like to know why, too. Drastic changes in performance may mean that faster ways to do a thing were discovered. It may also mean that codepaths are being skipped that are essential to things functioning correctly. Remember the Debian OpenSSL bug?
That's why I'd like to know why SSL signing is so much faster under the new kernel. Seeing a 2x improvement makes me wonder if something's been screwed up that could compromise my certs.
Re:Why dang it? (Score:4, Insightful)
Hey guys. Michael (Larabel, whom owns and runs Phoronix) isn't omnipotent and he does a lot to keep his site running, OS's and tasks benchmarked, and news up to date on top of extra projects like the Phoronix Benchmark Suite of which he has brought togethor almost exclusively by himself. Do yourselves a favour and do some research, and maybe even post it to Phoronix for Michael to update. Assist him and, subsequently, the rest of us to reduce the number of questions.
That is the question... (Score:2, Informative)
The Phoronix benchmarking is intended to provide you the answers as to why. It is to highlight the stuff that has happened.
If performance management is going on within the kernel community, then this shouldn't come up as a shock. The whole purpose of independent testing is that you see something that looks out of place, investigate and resolve. A perfect example is http://www.phoronix.com/scan.php?page=article&item=intel_atom_four&num=1 [phoronix.com] phoronix article, that showed that SuSE was trailing. Thi
Re: (Score:2)
What's so special about that example you gave?
openSuSE's disk I/O was slower because they enabled an option that the other didn't. Not enabling that option "runs the risk of severe filesystem corruption during a crash". Looks like they changed it to be like the other distros so they wouldn't look so bad during the benchmark.
That's nice. Compromise stability for performance. This is the type of stupid crap that makes people wonder... Gee, why is such and such so much faster?
The other issue was already report
Re: (Score:2)
What makes you think SuSE unconsciously made the trade off? The default setting is to have barriers disabled. They would have had to override the default behavior.
Re: (Score:2)
It's not quite that simple.
See that openSUSE bug [opensuse.org]:
Re: (Score:2)
If you bought a new oven and it had an option to reduce gas consumption but in "relatively rare" situations it could explode while you were cooking, what setting would you leave it on?
I've seen other things like this over the years, and that's why I am now deploying applications on Solaris. Like all software it's not completely bug free, but I haven't had any problems, and their philosophy seems to be to not intentionally make decisions that could blow people up.
Re: (Score:1)
Judging by your posts and your handle, you work in or around servers - a lot.
You would probably be aware that security, stability, and all such things are a set of tradeoffs of risks and benefits/costs.
You can make a system 100% secure, but it may not be useable. You can make a system five 9's stable, but you have to pay for it. You make the assessment of the risk (in this case data corruption), against the benefit/costs (double the speed in some cases).
SuSE seemed to have made the assessment of risk with
Re: (Score:2)
Or using your analogy. The tests that the oven may blow up but save 50% on the energy bill has been shown that the net benefit is on the side of the oven that may potentially blow up!
How so? The average yearly cost of an oven [michaelbluejay.com] is $42. You're telling me that you'd accept the risk of injury, possibly death to save $21 a year?
From my experience, most people don't have a cage, or even a rack full of servers that can sustain the loss of a single server going down.
Most don't even run at more than 40% utilization and the performance is not that important.
What is important is that their system is reliable and that they don't have to waste time rebuilding it.
The server and the operating system sh
imagemagic libraries?? (Score:3, Interesting)
Re: (Score:3, Interesting)
Note: I'm not defending the Phoronix guys. As a previous poster pointed out, they are inherently bad at explaining the why things are slower and sometimes they are flat out wrong [phoronix-test-suite.com]
Re: (Score:3, Insightful)
``Note: I'm not defending the Phoronix guys. As a previous poster pointed out, they are inherently bad at explaining the why things are slower and sometimes they are flat out wrong [phoronix-test-suite.com]''
In that case, the best they can do is to stop talking about it and just stick to what they know. Knowing just what is faster and what is slower is useful by itself. It can be used as a starting point for investigating what exactly caused the speed-ups and slowdowns. If the Phoronix folks can't or don't want to do this investigat
Boot time is better. (Score:5, Interesting)
fastboot: Asynchronous function calls to speed up kernel boot
fastboot: make scsi probes asynchronous
fastboot: make the libata port scan asynchronous
fastboot: make ACPI bus drivers probe asynchronous
fastboot: Make libata initialization even more async
I don't know for sure that all of this made it upstream for this release but I know some of it did. I think you have to pass the "fastboot" kernel line for it, however. So check your kernel configs and update your grubs!
Or LILOs, if you're weird...
Oh one more thing.. I think the introduction of the asynchronous probing and various other things are going to start a whole new wave of bootfast tricks. For example, before it tries mounting the root file system and continuing on, it waits for device probing to finish. A comment above that code states "Waiting for device probing to finish... This is known to cause long delays in boots, for example this can take 5 seconds for a laptop's touchpad to initialize". The comment was written by Arjan, who obviously has intention to speed things up. So I think what might happen is instead of waiting for EVERYTHING to finish probing (Even if it is async), it'll just wait for the filesystem to become available (Perhaps try after IDE probes, then try after SCSI probes, then after USB, and so on.)
I also remember there was a patch that didn't go upstream (I don't think so anyways) that added a function to be able to initialize things later on (After the boot was done). You changed the initialize() or whatever the function name was to initialize_later(), and then after you're done booting, whenever you want, you do a command and it then initializes anything you did the initialize_later() to. So you would be able to load up the webcam initialization or whatever else you know you don't use right when you boot.
Well, where I'm going with this is that I would like to see them incorporate more of that stuff into the kernel. More boot hacks, more power saving, more efficiency. These things are only going to improve.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
And they *do* test the shit out of kernels before releasing, you know..
Benchmarks used x86-64 (Score:1)