rcutorture: add random preemption
PATCH 1/1 rcutorture: add random preemption
Add random preemption to help we to torture the preemptable rcu.
srcu_read_delay() also calls rcu_read_delay() for shorter delays.
---
kernel/rcutorture.c +6 -0
@@ -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 } 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)
Quoted 3 lines · Lai Jiangshan
Add random preemption to help we to torture the preemptable rcu.
srcu_read_delay()also callsrcu_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
Quoted 7 lines
Signed-off-by Lai Jiangshan <[email protected]>---
kernel/rcutorture.c +0
-0
kernel/rcutorture.c static void rcu_read_delay(struct rcu_random_state *rrsp) · line 309
Quoted 7 lines
kernel/rcutorture.c +4
-0@@ -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?
Quoted 17 lines
kernel/rcutorture.c +2
-1} 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Paul E. McKenney
kernel/rcutorture.c static void rcu_read_delay(struct rcu_random_state *rrsp) · line 309
Quoted 4 lines
kernel/rcutorture.c +4
-0+#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?
Well it seems to do a !preempt_count() test too, so I wouldn't worry too much about it, still using preempt_schedule() doesn't seem right, why not use cond_resched()?
Quoted 10 lines · Peter Zijlstra
Quoted 9 lines · Paul E. McKenney
kernel/rcutorture.c static void rcu_read_delay(struct rcu_random_state *rrsp) · line 309
Quoted 4 lines
kernel/rcutorture.c +4
-0+#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.
Quoted 6 lines
Quoted 2 lines
So, should we have a comment to this effect, or is my hypersensitivity to RCU semantics unique to me?
Well it seems to do a !preempt_count() test too, so I wouldn't worry too much about it, still using
preempt_schedule()doesn't seem right, why not usecond_resched()?
My guess is that Lai wants to force a call to rcu_sched_qs() even if !need_resched(). One reason for doing this would be to put more stress on preemptible RCU's handling of context switches in RCU read-side critical sections.
Another approach would be to have some high-priority threads that wake up periodically, as I plan to make rcutorture do for RCU priority boosting. Of course, this is not necessarily mutually exclusive with Lai's approach.
Thanx, Paul
Quoted 14 lines · Paul E. McKenney
Quoted 13 lines · Peter Zijlstra
Quoted 11 lines · Paul E. McKenney
kernel/rcutorture.c static void rcu_read_delay(struct rcu_random_state *rrsp) · line 309
Quoted 4 lines
kernel/rcutorture.c +4
-0+#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?
Quoted 6 lines
Quoted 3 lines
Well it seems to do a !preempt_count() test too, so I wouldn't worry too much about it, still using
preempt_schedule()doesn't seem right, why not usecond_resched()?My guess is that Lai wants to force a call to
rcu_sched_qs()even if !need_resched().
Ah, d'0h yeah, I'm not having the best of days.. monday or something :-)