lkml.org 
[lkml]   [2023]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v2] rcutorture: Convert schedule_timeout_uninterruptible() to mdelay() in rcu_torture_stall()
Date
> From: Paul E. McKenney <paulmck@kernel.org>
> [...]
> > 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

\
 
 \ /
  Last update: 2023-03-27 01:10    [W:0.471 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site