> From: Paul E. McKenney <paulmck@xxxxxxxxxx>
> [...]
> > But invoke schedule_timeout_uninterruptible(HZ) implies a quiescent
> > state, this will not cause an RCU stall to occur, and still in the RCU read
> critical section(PREEMPT_COUNT=y).
> >
> > It didn't happen RCU stall when I tested with the following parameters
> > for
> > rcutorture.stall_cpu=30
> > rcutorture.stall_no_softlockup=1
> > rcutorture.stall_cpu_irqsoff=1
> > rcutorture.stall_cpu_block=1
>
> Understood. If you want that RCU CPU stall in a CONFIG_PREEMPTION=n
> kernel, you should not use rcutorture.stall_cpu_block=1.
>
Verified.
if rcutorture.stall_cpu_block=0, it can trigger the expected RCU CPU stall for either
torture_type=srcu or torture_type=rcu.
> In a CONFIG_PREEMPTION=y kernel, rcutorture.stall_cpu_block=1 forces the
> grace period to be stalled on a task rather than a CPU, exercising a different
> part of the RCU CPU stall warning code.
>
> In a CONFIG_PREEMPTION=n kernel, using rcutorture.stall_cpu_block=1
> forces the CPU to go through a quiescent state, as you say. It can also cause
> lockdep and scheduling-while-atomic complaints, depending on exactly what
> type of RCU reader is in effect.
>
Verified.
If rcutorture.stall_cpu_block=1:
There were lockdep and scheduling-while-atomic complaints for torture_type=rcu.
No lockdep and scheduling-while-atomic complaints for torture_type=srcu.
> So these are test-the-diagnostics parameters. The mdelay() instead makes
> rcutorture.stall_cpu_block=1 do the same thing as does
> rcutorture.stall_cpu_block=0 for CONFIG_PREEMPTION=n kernels, right?
Good to know that these are test-the-diagnostics parameters and their expected behaviors. ;-)
Thanks!
-Qiuxu
> Thanx, Paul
