rcu: Document SRCU dead-CPU capabilities, emphasize read-side limits
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Fri, 3 Aug 2012 23:41:23 +0000 (16:41 -0700)
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Sun, 23 Sep 2012 14:42:23 +0000 (07:42 -0700)
The current documentation did not help someone grepping for SRCU to
learn that disabling preemption is not a replacement for srcu_read_lock(),
so upgrade the documentation to bring this out, not just for SRCU,
but also for RCU-bh.  Also document the fact that SRCU readers are
respected on CPUs executing in user mode, idle CPUs, and even on
offline CPUs.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Documentation/RCU/checklist.txt
Documentation/RCU/whatisRCU.txt

index fc103d7a04740d338bf0490a2133674c25986d59..cdb20d41a44ad8992f2f7b6e13a01d0200c67a32 100644 (file)
@@ -310,6 +310,12 @@ over a rather long period of time, but improvements are always welcome!
        code under the influence of preempt_disable(), you instead
        need to use synchronize_irq() or synchronize_sched().
 
+       This same limitation also applies to synchronize_rcu_bh()
+       and synchronize_srcu(), as well as to the asynchronous and
+       expedited forms of the three primitives, namely call_rcu(),
+       call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),
+       synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().
+
 12.    Any lock acquired by an RCU callback must be acquired elsewhere
        with softirq disabled, e.g., via spin_lock_irqsave(),
        spin_lock_bh(), etc.  Failing to disable irq on a given
index 69ee188515e7a9c907ec243dfff21852e55a9998..bf0f6de2aa00c8d6ee482890bc2bd05434b772c2 100644 (file)
@@ -873,7 +873,7 @@ d.  Do you need to treat NMI handlers, hardirq handlers,
        and code segments with preemption disabled (whether
        via preempt_disable(), local_irq_save(), local_bh_disable(),
        or some other mechanism) as if they were explicit RCU readers?
-       If so, you need RCU-sched.
+       If so, RCU-sched is the only choice that will work for you.
 
 e.     Do you need RCU grace periods to complete even in the face
        of softirq monopolization of one or more of the CPUs?  For
@@ -884,7 +884,12 @@ f. Is your workload too update-intensive for normal use of
        RCU, but inappropriate for other synchronization mechanisms?
        If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!
 
-g.     Otherwise, use RCU.
+g.     Do you need read-side critical sections that are respected
+       even though they are in the middle of the idle loop, during
+       user-mode execution, or on an offlined CPU?  If so, SRCU is the
+       only choice that will work for you.
+
+h.     Otherwise, use RCU.
 
 Of course, this all assumes that you have determined that RCU is in fact
 the right tool for your job.