The Huge Disaster Within The Linux 2.6.35 Kernel

The performance of the Linux 2.6.35 kernel code right now is a disaster. There is no other way to put this situation. While, yes, there still is a number of weeks left before the Linux 2.6.35 kernel release, it's inexplicable that a regression like this or change in behavior can even be accepted into the mainline Git tree at any point in the development cycle for such a mature project. That it can not only enter the kernel tree, but it can live for a week or more without either being corrected or the problematic commit being reverted. This is such a glaring performance issue across so many different tests and differently configured systems that it calls to question the current development practices and test procedures of the Linux kernel. These performance problems are affecting systems from Atom desktops to multi-core, high-end notebooks in tests from media encoding to synthetic disk tests.

As we have already shown before, using the Phoronix Test Suite and its components we can also narrow down to the individual commit(s) that introduced these serious performance issues by layering the Phoronix Test Suite's automated support atop the git-bisect command to automatically traverse the tree and perform tests at each step of the process. We may do so again in this instance -- time or incentive permitting -- to track down this newest problem. Alternatively, you can too since the Phoronix Test Suite is indeed open-source. It is already can be as simple as installing a kernel prior to 2010-05-20, a post-2010-05-22 kernel, and then running a command like phoronix-test-suite benchmark hmmer. Projects can also take advantage of our public Phoromatic server as we use for our current trackers after downloading the Phoronix Test Suite. We are also more than happy to work with the Linux kernel community or any other software project in establishing more robust test procedures and greater test coverage. We will work with other vendors too, via our commercial entity.

Stay tuned to see how this bewildering performance problem is resolved and whether such a severe performance regression makes it again into the mainline code-base.