[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080619092914.GB15228@elte.hu>
Date: Thu, 19 Jun 2008 11:29:14 +0200
From: Ingo Molnar <mingo@...e.hu>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, josh@...edesktop.org,
dvhltc@...ibm.com, niv@...ibm.com, dino@...ibm.com,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
vegard.nossum@...il.com, adobriyan@...il.com, oleg@...sign.ru,
bunk@...nel.org, rjw@...k.pl
Subject: Re: [PATCH] Make rcutorture more vicious: reinstate boot-time
testing
* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> Hello again!
>
> This patch re-institutes the ability to build rcutorture directly into
> the Linux kernel. The reason that this capability was removed was
> that this could result in your kernel being pretty much useless, as
> rcutorture would be running starting from early boot. This problem
> has been avoided by (1) making rcutorture run only three seconds of
> every six by default, (2) adding a CONFIG_RCU_TORTURE_TEST_RUNNABLE
> that permits rcutorture to be quiesced at boot time, and (3) adding a
> sysctl in /proc named /proc/sys/kernel/rcutorture_runnable that
> permits rcutorture to be quiesced and unquiesced when built into the
> kernel.
>
> Please note that this /proc file is -not- available when rcutorture is
> built as a module. Please also note that to get the earlier
> take-no-prisoners behavior, you must use the boot command line to set
> rcutorture's "stutter" parameter to zero.
>
> The rcutorture quiescing mechanism is currently quite crude: loops in
> each rcutorture process that poll a global variable once per tick.
> Suggestions for improvement are welcome. The default action will be
> to reduce the polling rate to a few times per second.
applied to tip/core/rcu - thanks Paul!
FYI, yesterday's rcutorture-stutter feature survived a few hundred
random bootup tests in -tip testing already.
a possible area for enhancement would be the following code:
static void
rcu_stutter_wait(void)
{
while (stutter_pause_test || !rcutorture_runnable)
schedule_timeout_interruptible(1);
}
will cause HZ number of IRQs on nohz systems, even if rcutorture is
disabled. While it's fine to poll if rcutorture_runnable==1, the sleep
should be at least 1 second when !rcutorture_runnable.
[ Or it might even make sense to completely stop the threads from a
sysctl handler - to make it event-driven and to cause no extra IRQs at
all when rcutorture is disabled via /proc. ]
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists