[lkml]   [1997]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux Stability & cold.system

    > 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 ----> <><

     \ /
      Last update: 2005-03-22 13:40    [W:0.020 / U:40.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site