Subject: Re: [PATCH] RCU torture testing
From: Arjan van de Ven <arjan@infradead.org>
To: paulmck@us.ibm.com
Cc: Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org, akpm@osdl.org,
       dipankar@in.ibm.com, vatsa@in.ibm.com, rusty@au1.ibm.com, mingo@elte.hu,
       manfred@colorfullife.com
In-Reply-To: <20051003143009.GB1300@us.ibm.com>
References: <20051001182056.GA1613@us.ibm.com>
	 <20051002210549.GA8503@elf.ucw.cz>  <20051003143009.GB1300@us.ibm.com>
Content-Type: text/plain
Date: Mon, 03 Oct 2005 16:36:28 +0200
Message-Id: <1128350188.17024.14.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1867
Lines: 41

On Mon, 2005-10-03 at 07:30 -0700, Paul E. McKenney wrote:
> On Sun, Oct 02, 2005 at 11:05:49PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > The attached patch adds CONFIG_RCU_TORTURE_TEST, which enables a /proc-based
> > > intense torture test of the RCU infrastructure.  This is needed due to the
> > > continued changes to RCU infrastructure to accommodate dynamic ticks, CPU
> > > hotplug, and so on.  Most of the code is in a separate file that is compiled
> > > only if the CONFIG variable is set.  Documentation on how to run the test
> > > and interpret the output is also included.
> > > 
> > > This code has been tested on i386 and ppc64, and an earlier version of the
> > > code has seen extensive testing on a number of architectures as part of the
> > > PREEMPT_RT patchset.
> > > 
> > > Signed-off-by: <paulmck@us.ibm.com>
> > 
> > Can you just run the tests from time to time inside IBM?
> 
> In principle, I could, but in practice it is appropriate for non-IBMers to
> be able to test the RCU infrastructure easily and thoroughly when they
> work on it.

how hard would it be to make the few parameters just be module
options... and then fail module load if the test fails or something?
(and spew loudly in dmesg :)

I'd be all in favor of having such a module in the kernel; in fact it
would be nice if we roughly could standardize on an way to load/start
and then find the result, I'd love to have a "make runtests" or
something that would load such modules one by one

(and no that's not the task of ltp, ltp should test userspace; things
that test in kernel code should really be part of the kernel)


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