]> asedeno.scripts.mit.edu Git - linux.git/commitdiff
srcu: Document auto-expediting requirement
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Thu, 27 Apr 2017 20:16:15 +0000 (13:16 -0700)
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Thu, 8 Jun 2017 15:25:33 +0000 (08:25 -0700)
This commit documents the auto-expediting requirement satisfied by
commits 2da4b2a7fd8d ("srcu: Expedite first synchronize_srcu() when idle")
and 22607d66bbc3 ("srcu: Specify auto-expedite holdoff time").

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Documentation/RCU/Design/Requirements/Requirements.html

index f60adf112663aad038e928e7b7cce04a65752277..8bbf0bb1838956372d50a6c5d68466cbfa78b1ad 100644 (file)
@@ -2935,6 +2935,20 @@ The reason that this is possible is that SRCU is insensitive
 to whether or not a CPU is online, which means that <tt>srcu_barrier()</tt>
 need not exclude CPU-hotplug operations.
 
+<p>
+SRCU also differs from other RCU flavors in that SRCU's expedited and
+non-expedited grace periods are implemented by the same mechanism.
+This means that in the current SRCU implementation, expediting a
+future grace period has the side effect of expediting all prior
+grace periods that have not yet completed.
+(But please note that this is a property of the current implementation,
+not necessarily of future implementations.)
+In addition, if SRCU has been idle for longer than the interval
+specified by the <tt>srcutree.exp_holdoff</tt> kernel boot parameter
+(25&nbsp;microseconds by default),
+and if a <tt>synchronize_srcu()</tt> invocation ends this idle period,
+that invocation will be automatically expedited.
+
 <p>
 As of v4.12, SRCU's callbacks are maintained per-CPU, eliminating
 a locking bottleneck present in prior kernel versions.