From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] rcutorture: add random preemption
Date: Mon, 21 Jun 2010 09:43:06 -0700 [thread overview]
Message-ID: <20100621164306.GC2354@linux.vnet.ibm.com> (raw)
In-Reply-To: <4C1F2986.7080006@cn.fujitsu.com>
On Mon, Jun 21, 2010 at 04:57:42PM +0800, Lai Jiangshan wrote:
> Add random preemption to help we to torture the preemptable rcu.
>
> srcu_read_delay() also calls rcu_read_delay() for shorter delays.
I do like the change to srcu_read_delay(), good to fall back to the
normal rcu_read_delay() behavior when a long delay is not selected.
The change to rcu_read_delay() looks promising as well, but please see
below for some comments on the other change.
And the big question: did you find any failures when testing with this
change? ;-)
Thanx, Paul
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> index 2e2726d..7c81d07 100644
> --- a/kernel/rcutorture.c
> +++ b/kernel/rcutorture.c
> @@ -303,6 +303,10 @@ static void rcu_read_delay(struct rcu_random_state *rrsp)
> mdelay(longdelay_ms);
> if (!(rcu_random(rrsp) % (nrealreaders * 2 * shortdelay_us)))
> udelay(shortdelay_us);
> +#ifdef CONFIG_PREEMPT
> + if (!preempt_count() && !(rcu_random(rrsp) % (nrealreaders * 20000)))
> + preempt_schedule();
> +#endif
This one scared me for a bit -- then I realized that preempt_schedule()
won't actually schedule if preemption is in any way disabled. So the
above really is OK, because Classic RCU and RCU-bh disable preemption.
So, should we have a comment to this effect, or is my hypersensitivity to
RCU semantics unique to me?
> }
>
> static void rcu_torture_read_unlock(int idx) __releases(RCU)
> @@ -536,6 +540,8 @@ static void srcu_read_delay(struct rcu_random_state *rrsp)
> delay = rcu_random(rrsp) % (nrealreaders * 2 * longdelay * uspertick);
> if (!delay)
> schedule_timeout_interruptible(longdelay);
> + else
> + rcu_read_delay(rrsp);
> }
>
> static void srcu_torture_read_unlock(int idx) __releases(&srcu_ctl)
> --
> 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/
next prev parent reply other threads:[~2010-06-21 16:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 8:57 [PATCH] rcutorture: add random preemption Lai Jiangshan
2010-06-21 16:43 ` Paul E. McKenney [this message]
2010-06-21 16:50 ` Peter Zijlstra
2010-06-21 17:05 ` Paul E. McKenney
2010-06-21 17:06 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100621164306.GC2354@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.