RE: [PATCH v2] rcutorture: Convert schedule_timeout_uninterruptible() to mdelay() in rcu_torture_stall()

[Zhuo, Qiuxu]

> 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