[linux] Test rychlosti jadra Linuxu

[Milan Kerslager]

Ahoj,

cetl jsem starou postu z Aprila a prislo mi lito neodpovedet i pres tak
dlouhou dobu od polozeni otazky :-)


---------- Forwarded message ----------
Date: Thu, 10 Aug 2000 11:35:03 -0400
From: David Mansfield <lkml na dm.ultramaster.com>
To: Nathan Straz <nstraz na sgi.com>, lkml <linux-kernel na vger.rutgers.edu>
Subject: Re: [Announce] Linux Test Project

Nathan Straz wrote:
> 
> SGI would like to announce the Linux Test Project.  The goal of this
> project is to create a formalized test system for the Linux kernel.
> 
> We have released a set of 96 tests on the project's website
> (http://oss.sgi.com/projects/ltp/).  These tests exercise file systems
> and system calls and can be used for stress testing or sanity tests.
> 

One question: how is the framework going to handle tests which cause
pathological behavior in the kernel.  For example, 'infinite' hangs in
the MM system during OOM, or crashes (OOPSes, panics) or deadlocks
(process stuck in 'D' state).  Most often these are the results of the
tests I tend to run.

Any testbed needs to handle these situations, at least somewhat.  For
example, if I leave a 12 hour regression going and leave the console,
and I come back to see the system has rebooted itself, or is stuck solid
- how do I know which test has 'failed'?

Ideally, in the case where something bad but not as fatal as complete
lockup happens, the test bed should diagnose the fault.  This could be
capturing the oops, or running ps -alx to see where it's stuck.

In all the cases where I've tested the kernel, it has been a matter of
'Here is the test which crashes the kernel, let's see if it crashes this
one, too' and I just want to throw this into the consideration of how to
best create a test harness.

David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo na vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/