Re: Linux Stability & cold.system

Adam D. Bradley (
Mon, 17 Nov 1997 12:26:37 -0500 (EST)

> So, some people (myself included) have put forth some ideas on some way
> of actually MEASURING the stability of kernels. One of my favorite was
> one somebody else mentioned: have a utility kind of like the 'make
> check' things that come with bash that tests the kernel currently
> running for stability, memory leaks, etc. I know people have
> "kernel-killers" out there :) If some standard test suite were
> available, then everyone could upload their results.

I've been (unofficially, of course) collecting stress scripts since a
similar thread back in September. I'm hoping to put together a
package of them around Christmastime for everyone's enjoyment.
Naturally, I'm looking for additional suggestions from everyone on the
list; what are the "killer scripts" and other killer workload
generators you use to torture those "small, fuzzy kernels"? ;-)

Another idea, and this is currently only conceptual, is a "correctness
testing" suite. The idea is, the various components of the kernel
(the .a or even .o files) could be linked against appropriate
libraries and test modules; the result, you could test kernel
components in userspace, without having to boot them, and in a "safe"
environment (so you can prevent it from mangling your directory tree,
for example). Basic linux/lib stuff would naturally have to be
re-implemented for usermode, eg "get_free_page" could allocate out of
a massive malloced slab of memory, etc.

Of course, it suffers some weaknesses; every time any API or its
semantics changed the libs would need to be updated, but these are
supposed to be relatively stable. Simulating multi-process cases
would be fairly straightforward (by using a "test" implementation of
sleeping functions etc), but deciding which ones are _interesting_ to
simulate is another matter ;-) ... SMP case simulation would also be
possible using pthreads, I suppose.

Anyone else think this would be a worthwhile effort?

> However, although
> we can test much of the kernel pretty well, we might have some
> difficulty testing wierd components. I suppose we could try to get each
> developer to write a stress-tester for his/her subsystem.

I know Ted T'so has/had a suite of tests he ran on ext2 before
releasing any substantive changes. This makes sense with software
components (filesystems, non-hardware networking layers, etc) but
hardware drivers are (unfortunately) best tested by "see if this works
for you as well as it does for me".

Just thoughts,

Things look so bad everywhere      Adam D. Bradley
In this whole world what is fair        Boston University Computer Science
We walk blind and we try to see             Ph.D. student and Linux hacker
Falling behind in what could be  ---->  Bring me a Higher Love  ---->  <><