doc: Eliminate cond_resched_rcu_qs() in favor of cond_resched()
Now that cond_resched() also provides RCU quiescent states when needed, it can be used in place of cond_resched_rcu_qs(). This commit therefore documents this change. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This commit is contained in:
parent
388a4c8806
commit
f2b1760aed
|
@ -1097,7 +1097,8 @@ will cause the CPU to disregard the values of its counters on
|
|||
its next exit from idle.
|
||||
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
|
||||
cases where a given operation has resulted in a quiescent state
|
||||
for all flavors of RCU, for example, <tt>cond_resched_rcu_qs()</tt>.
|
||||
for all flavors of RCU, for example, <tt>cond_resched()</tt>
|
||||
when RCU has indicated a need for quiescent states.
|
||||
|
||||
<h5>RCU Callback Handling</h5>
|
||||
|
||||
|
|
|
@ -2797,7 +2797,7 @@ RCU must avoid degrading real-time response for CPU-bound threads, whether
|
|||
executing in usermode (which is one use case for
|
||||
<tt>CONFIG_NO_HZ_FULL=y</tt>) or in the kernel.
|
||||
That said, CPU-bound loops in the kernel must execute
|
||||
<tt>cond_resched_rcu_qs()</tt> at least once per few tens of milliseconds
|
||||
<tt>cond_resched()</tt> at least once per few tens of milliseconds
|
||||
in order to avoid receiving an IPI from RCU.
|
||||
|
||||
<p>
|
||||
|
@ -3128,7 +3128,7 @@ The solution, in the form of
|
|||
is to have implicit
|
||||
read-side critical sections that are delimited by voluntary context
|
||||
switches, that is, calls to <tt>schedule()</tt>,
|
||||
<tt>cond_resched_rcu_qs()</tt>, and
|
||||
<tt>cond_resched()</tt>, and
|
||||
<tt>synchronize_rcu_tasks()</tt>.
|
||||
In addition, transitions to and from userspace execution also delimit
|
||||
tasks-RCU read-side critical sections.
|
||||
|
|
|
@ -23,12 +23,10 @@ o A CPU looping with preemption disabled. This condition can
|
|||
o A CPU looping with bottom halves disabled. This condition can
|
||||
result in RCU-sched and RCU-bh stalls.
|
||||
|
||||
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
|
||||
kernel without invoking schedule(). Note that cond_resched()
|
||||
does not necessarily prevent RCU CPU stall warnings. Therefore,
|
||||
if the looping in the kernel is really expected and desirable
|
||||
behavior, you might need to replace some of the cond_resched()
|
||||
calls with calls to cond_resched_rcu_qs().
|
||||
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
|
||||
without invoking schedule(). If the looping in the kernel is
|
||||
really expected and desirable behavior, you might need to add
|
||||
some calls to cond_resched().
|
||||
|
||||
o Booting Linux using a console connection that is too slow to
|
||||
keep up with the boot-time console-message rate. For example,
|
||||
|
|
Loading…
Reference in a new issue