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."
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.
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.
imagemagic libraries?? (Score:3, Interesting)
Re:imagemagic libraries?? (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]
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: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.