Commit 09f501a0 authored by Paul E. McKenney's avatar Paul E. McKenney

srcu: Document auto-expediting requirement

This commit documents the auto-expediting requirement satisfied by
commits 2da4b2a7 ("srcu: Expedite first synchronize_srcu() when idle")
and 22607d66 ("srcu: Specify auto-expedite holdoff time").
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
parent 5d9853f3
...@@ -2935,6 +2935,20 @@ The reason that this is possible is that SRCU is insensitive ...@@ -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> to whether or not a CPU is online, which means that <tt>srcu_barrier()</tt>
need not exclude CPU-hotplug operations. 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> <p>
As of v4.12, SRCU's callbacks are maintained per-CPU, eliminating As of v4.12, SRCU's callbacks are maintained per-CPU, eliminating
a locking bottleneck present in prior kernel versions. a locking bottleneck present in prior kernel versions.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment