Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

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

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

Documentation/RCU/Design/Requirements/Requirements.html

+14 −0
Original line number Original line Diff line number Diff line
@@ -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.