[Ksummit-2012-discuss] [ATTEND] writeback and kernel testing
fengguang.wu at intel.com
Sun Jun 17 02:19:07 UTC 2012
On Sat, Jun 16, 2012 at 06:29:49PM -0700, H. Peter Anvin wrote:
> On 06/16/2012 06:18 PM, Guenter Roeck wrote:
> > On Sat, Jun 16, 2012 at 10:50:41PM +0800, Fengguang Wu wrote:
> > [ ... ]
> >> Yeah, that should be a pretty common impression. The hardware
> >> capability and the fruit of catching one bug per day turns out to be
> >> much higher than my expectation :-)
> > How many servers do you actually need to compile 25k kernels per day ?
> > With my little system (i7-2600, SSD) I get about 1,000 randconfig kernel builds
> > per 24 hours, so it should not be too many.
> It would be nice to have a "kernel testing appliance" -- rather than a
> bunch of people writing similar stuff have something that anyone with
> spare hardware can put on a system. Bonus points if it actually can
> drive a physical test box, too. I think tglx was working on something
> like that at one point; Ingo has a setup like that but it is apparently
> extremely ad hoc.
It's definitely feasible.
Kernel builds can be naturally distributed by arranging each compile
server to focus on a different set of git trees. Given the ever
increasing CPU cores and computation power, several such compile
servers should be enough.
Distributable runtime tests can be much more valuable. My current kvm
based tests are already distributable (at least inside Intel campus):
the test box runs several instances of kvm, each fetching new kernels
from the compile server via HTTP. Then send back the dmesg if it hangs
or contains any kernel oops/warnings. HTTP means anyone may trivially
setup a box on the other side of earth and help test out new kernels :-)
Physical test boxes would be even more valuable. I've addressed the
boot problem with gpxe or kexec, both supports HTTP kernel fetching.
The main difficulty is how to get the dmesg back. Most PC boxes don't
have serial console at all..
More information about the Ksummit-2012-discuss