Design/Requirements/Requirements.rst

67 RCU's grace-period guarantee is unusual in being premeditated: Jack
73 RCU's grace-period guarantee allows updaters to wait for the completion
185 | Without that extra grace period, memory reordering could result in    |
196 Although RCU's grace-period guarantee is useful in and of itself, with
199 data structures. For this, the grace-period guarantee is not sufficient,
414 This function is straightforward, with line 13 waiting for a grace
459 can be used in combination with the grace-period guarantee to also allow
530 | code, why does it matter how it relates to a grace period?” The       |
534 | preceding and following the grace period. If we take this viewpoint,  |
536 | grace period when some access preceding the grace period observes the |
539 | of any access following the grace period.                             |
570 | end of the RCU read-side critical section and the end of the grace    |
587 | grace period and the beginning of the RCU read-side critical section, |
625 fundamental RCU requirement that a grace period wait for all
699 through their interaction with the grace-period APIs such as
753 All they do is to prevent grace periods from ending. The following
781 aside from subsequent grace periods, of which ``thread1()`` has none, so
812 section precedes a given grace period, and if any part of another RCU
813 read-side critical section follows that same grace period, then all of
815 However, this just isn't the case: A single grace period does not
855 section that started before the current grace period:
860 manner, it is necessary to use two grace periods, where the first grace
861 period is known to end before the second grace period starts:
896 before the end of ``thread1()``'s grace period. If in addition
898 the beginning of ``thread2()``'s grace period. If it is also the case
899 that ``(r2 == 1)``, then the end of ``thread1()``'s grace period must
900 precede the beginning of ``thread2()``'s grace period. This mean that
917 happens between a pair of grace periods, then those grace periods cannot
972 given grace period, just so long as it does not overlap the entire grace
974 a pair of RCU grace periods.
979 | How long a sequence of grace periods, each separated by an RCU        |
1212 The ``synchronize_rcu()`` grace-period-wait primitive is optimized for
1217 they can be satisfied by a single underlying grace-period-wait
1219 single grace-period-wait operation to serve more than `1,000 separate
1222 down to nearly zero. However, the grace-period optimization is also
1228 used instead, reducing the grace-period latency down to a few tens of
1242 ``synchronize_rcu_expedited()``'s reduced grace-period latency is
1279 on line 25, and will be invoked after the end of a subsequent grace
1281 without forcing the updater to wait for a grace period to elapse. The
1343 subsequent grace period and ``kfree()``. It is permissible to invoke
1357 | of the memory (respectively) must still wait for a grace period to    |
1368 | ``kfree_rcu()``, without having to wait for a subsequent grace        |
1373 executed after the end of the grace period, but has other tasks that can
1402 immediately if a grace period has elapsed in the meantime, but otherwise
1413 In theory, delaying grace-period completion and callback invocation is
1421 definition prevent later grace periods from ever completing. For a more
1426 allowing grace periods to complete), CPU 0 simply will not be able to
1431 to ensure timely completion of grace periods and timely invocation of
1434 RCU takes the following steps to encourage timely completion of grace
1437 #. If a grace period fails to complete within 100 milliseconds, RCU
1451 #. If a CPU is still holding out 10 seconds into the grace period, RCU
1468 #. Starts a grace period, if one is not already in progress.
1471    grace period.
1472 #. Immediately tags the CPU's callbacks with their grace period
1519 grace period cannot be enclosed in another RCU read-side critical
1520 section. This is because it is not legal to wait for a grace period
1544 block grace periods: As long as all the RCU read-side critical sections
1545 are finite, grace periods must also be finite.
1559 requirement is another factor driving batching of grace periods, but it
1574 starting grace periods and more aggressively forcing completion of
1575 grace-period processing. This evasive action causes the grace period to
1577 optimizations, thus increasing the CPU overhead incurred by that grace
1617    grace period in between. (This error is similar to a double free.)
1633    is not obligated to produce this splat unless there is a grace period
1636    Some extreme workloads might intentionally delay RCU grace periods,
1769 itself is a quiescent state and thus a grace period, so the early-boot
1781 required to correctly handle synchronous grace periods during this time
1788 | How can RCU possibly handle grace periods before all of its kthreads  |
1796 | all synchronous grace periods are handled by the expedited            |
1797 | grace-period mechanism. At runtime, this expedited mechanism relies   |
1799 | drives the desired expedited grace period. Because dead-zone          |
1801 | dead zone ends, expedited grace periods go back to using workqueues,  |
1803 | user task received a POSIX signal while driving an expedited grace    |
1886    *not*, obligated to wait for a grace period. It is instead only required
1891    to wait for a grace period.
1896 | Wait a minute! Each RCU callbacks must wait for a grace period to     |
1899 | wait for a full grace period if there is even one callback posted     |
1905 | Yes, each RCU callbacks must wait for a grace period to complete, but |
1908 | need only wait for the remaining portion of the grace period to       |
1912 | So if you need to wait for a grace period as well as for all          |
1932 grace-period operations such as ``synchronize_rcu()`` and
2156    (11-second) grace periods, with a pointless IPI waking the CPU from
2225 waiting for a grace period to elapse. It is also the reason why
2239 remain zero during all phases of grace-period processing, and that bit
2313 motivated the grace-period kthread, which also simplified handling of a
2381 grace periods from ever ending. The result was an out-of-memory
2388 offline. This means that RCU-bh grace periods can complete even when
2428 Before preemptible RCU, waiting for an RCU grace period had the side
2434 RCU-sched grace period waits for pre-existing interrupt and NMI
2480 in one domain does not delay an SRCU grace period in some other domain.
2496 sections, then that domain's grace periods will also be blocked forever.
2499 section can wait, either directly or indirectly, for that domain's grace
2530 invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
2535 an SRCU grace period, that grace period is waiting on a timer, and that
2542 non-expedited grace periods are implemented by the same mechanism. This
2543 means that in the current SRCU implementation, expediting a future grace
2544 period has the side effect of expediting all prior grace periods that
2613 increase grace-period latency with increasing numbers of CPUs. If this
2615 grace-period state machine so as to avoid the need for the additional
2624 The tradeoff between grace-period latency on the one hand and
2626 re-examined. The desire is of course for zero grace-period latency as
2628 grace period operation. While this ideal is unlikely to be achievable,
2662 guarantees under heavy load for grace periods and for callback