Back in October we made it possible to autonomously find performance regressions
in a project's code-base by leveraging the Phoronix Test Suite
atop Git's bisect command. A new Phoronix Test Suite module was created that would automatically run a binary search on a defined code-base and keep running the specified test(s) on each revision and then traverse to the next using Git bisect until the lone commit causing the defined regression was located. In that article we demonstrated this module by finding the commit that caused a serious performance drop for EXT4 by default in the Linux 2.6.32 kernel. While this feature is great for finding a regression that occurred at some point in the past, with the Phoronix Test Suite you can find regressions nearly in real-time now that Phoromatic
is available to the public.
Phoromatic is our enterprise-oriented remote test management software that makes it possible to routinely run any Phoronix Test Suite tests on a scheduled basis and everything continues to be carried out in a fully autonomous manner. Multiple test systems can also be controlled through the single web-based interface where the test results are then automatically uploaded to for easy viewing. Phoromatic makes it easy to build a benchmarking test farm
whether you are just an individual or a company.
With Phoromatic churning along, the Phoronix Kernel Test Farm
entered an operational state at the beginning of this month. With our test farm, the latest Linux kernel bits are automatically tested on a daily basis in an effort to track positive or negative performance changes.
There were no plans to then publicly unveil the new Phoronix Kernel Test Farm tracker web interface until the start of the new year once sufficient data has started to collect, but that has now changed. In less than two weeks of running the Phoronix Kernel Test Farm, our software has already latched on to yet another major, negative performance regression that is still present in the mainline tree and is poised to inhibit the performance of the Linux 2.6.33 kernel if it remains.
This Linux 2.6.33 performance regression is not minor, but in some tests is causing double digit changes. It looks like this regression has gone unnoticed by the stakeholders within the Linux kernel community, but now we are rushing to get this new public interface that exposes our kernel test farm to the public up and running. This should be live by next week, at which point the regression will be disclosed -- that is if the conventional Linux kernel testing methods don't prevail, which so far seems to be the case. The status quo is not sufficient if commits containing sizable regressions that can be easily spotted with real-world, automated tests are allowed to enter the mainline Linux kernel in the first place.