Testing for kernel performance regressions [LWN.net]

Testing for kernel performance regressions

Posted Aug 4, 2012 12:08 UTC (Sat) by robert_s (subscriber, #42402)
In reply to: Testing for kernel performance regressions by man_ls
Parent article: Testing for kernel performance regressions

Hardware is generally full of subtle bugs and to properly encapsulate them, you basically need a VHDL model of the hardware (that's what VHDL was originally designed for).

to post comments

Testing for kernel performance regressions

Posted Aug 4, 2012 15:21 UTC (Sat) by man_ls (guest, #15091) [Link] (3 responses)

In this case, anything is better than nothing. The more esoteric specialized hardware will probably harder to emulate; but just testing the most common hardware interfaces would surely save a lot of time and eventually enable devs to change code that may be currently too brittle to touch.

Some examples: mount a virtualized SATA disk, format it, create a few files, read them back and check their contents. Mount a virtualized USB disk and do the same. Create several filesystems and stress-test them. Check that the commands issued are in correct order. And so on.

This is (obviously) spoken from utter ignorance of kernel internals, just from the point of view of basic software engineering: if it is not tested and verified it is not finished. I am sure kernel devs will know how to implement the idea or ignore it if the effort is not worth it. But for me it would be a fascinating project.

Testing for kernel performance regressions

Posted Aug 4, 2012 19:09 UTC (Sat) by robert_s (subscriber, #42402) [Link] (2 responses)

"but just testing the most common hardware interfaces would surely save a lot of time"

But that's the stuff that gets tested anyway, by people. The trouble _is_ with the esoteric hardware.

Testing for kernel performance regressions

Posted Aug 4, 2012 22:39 UTC (Sat) by man_ls (guest, #15091) [Link] (1 responses)

Yes, so it is wasting the time of those people who have to painstakingly compile -rc kernels, load them and check that everything works. Not to speak about performance regressions in the drivers and filesystems, which I imagine must be hard to find and boring work. While a test suite publicly available might be run privately and also on the public git repos after every push. It is called continuous deployment, we do it at my company and it is fun, challenging stuff!

Testing for kernel performance regressions

Posted Aug 6, 2012 11:17 UTC (Mon) by niner (guest, #26151) [Link]

Testing RC kernels is not that hard. On openSUSE I just added the Kernel_HEAD repo and new kernels are installed with the other package updates. If a kernel breaks my system I can still just boot the old one and report the bug.

Testing for kernel performance regressions

Posted Aug 6, 2012 10:27 UTC (Mon) by njd27 (subscriber, #5770) [Link]

Unfortunately simulating VHDL would in most cases be far too slow to perform a realistic test of the kernel.

I actually work on the Linux driver for a particular family of input devices from one manufacturer. Most of the customers are integrating devices which are targeting older kernel versions rather than mainline, so our main focus is there. But we do track patches that are going into mainline and make sure they are sane, and do some occasional testing.