Lines Matching refs:grace
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,
415 This function is straightforward, with line 13 waiting for a grace
460 can be used in combination with the grace-period guarantee to also allow
531 | code, why does it matter how it relates to a grace period?” The |
535 | preceding and following the grace period. If we take this viewpoint, |
537 | grace period when some access preceding the grace period observes the |
540 | of any access following the grace period. |
571 | end of the RCU read-side critical section and the end of the grace |
588 | grace period and the beginning of the RCU read-side critical section, |
626 fundamental RCU requirement that a grace period wait for all
700 through their interaction with the grace-period APIs such as
754 All they do is to prevent grace periods from ending. The following
782 aside from subsequent grace periods, of which thread1() has none, so
813 section precedes a given grace period, and if any part of another RCU
814 read-side critical section follows that same grace period, then all of
816 However, this just isn't the case: A single grace period does not
856 section that started before the current grace period:
861 manner, it is necessary to use two grace periods, where the first grace
862 period is known to end before the second grace period starts:
897 before the end of thread1()'s grace period. If in addition
899 the beginning of thread2()'s grace period. If it is also the case
900 that ``(r2 == 1)``, then the end of thread1()'s grace period must
901 precede the beginning of thread2()'s grace period. This mean that
918 happens between a pair of grace periods, then those grace periods cannot
973 given grace period, just so long as it does not overlap the entire grace
975 a pair of RCU grace periods.
980 | How long a sequence of grace periods, each separated by an RCU |
1213 The synchronize_rcu() grace-period-wait primitive is optimized for
1218 they can be satisfied by a single underlying grace-period-wait
1220 single grace-period-wait operation to serve more than `1,000 separate
1223 down to nearly zero. However, the grace-period optimization is also
1229 used instead, reducing the grace-period latency down to a few tens of
1243 synchronize_rcu_expedited()'s reduced grace-period latency is
1280 on line 25, and will be invoked after the end of a subsequent grace
1282 without forcing the updater to wait for a grace period to elapse. The
1344 subsequent grace period and kfree(). It is permissible to invoke
1358 | of the memory (respectively) must still wait for a grace period to |
1369 | kfree_rcu(), without having to wait for a subsequent grace |
1374 executed after the end of the grace period, but has other tasks that can
1403 immediately if a grace period has elapsed in the meantime, but otherwise
1414 In theory, delaying grace-period completion and callback invocation is
1422 definition prevent later grace periods from ever completing. For a more
1427 allowing grace periods to complete), CPU 0 simply will not be able to
1432 to ensure timely completion of grace periods and timely invocation of
1435 RCU takes the following steps to encourage timely completion of grace
1438 #. If a grace period fails to complete within 100 milliseconds, RCU
1452 #. If a CPU is still holding out 10 seconds into the grace period, RCU
1469 #. Starts a grace period, if one is not already in progress.
1472 grace period.
1473 #. Immediately tags the CPU's callbacks with their grace period
1520 grace period cannot be enclosed in another RCU read-side critical
1521 section. This is because it is not legal to wait for a grace period
1545 block grace periods: As long as all the RCU read-side critical sections
1546 are finite, grace periods must also be finite.
1560 requirement is another factor driving batching of grace periods, but it
1575 starting grace periods and more aggressively forcing completion of
1576 grace-period processing. This evasive action causes the grace period to
1578 optimizations, thus increasing the CPU overhead incurred by that grace
1618 grace period in between. (This error is similar to a double free.)
1634 is not obligated to produce this splat unless there is a grace period
1637 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
1948 timers and grace period processing. It does so by maintaining its own set
1954 if offline CPUs block an RCU grace period for too long.
1959 2. When grace period initialization (rcu_gp_init()) detects a
1970 between RCU's hotplug notifier hooks, the grace period initialization
2186 (11-second) grace periods, with a pointless IPI waking the CPU from
2255 waiting for a grace period to elapse. It is also the reason why
2269 remain zero during all phases of grace-period processing, and that bit
2343 motivated the grace-period kthread, which also simplified handling of a
2411 grace periods from ever ending. The result was an out-of-memory
2418 offline. This means that RCU-bh grace periods can complete even when
2458 Before preemptible RCU, waiting for an RCU grace period had the side
2464 RCU-sched grace period waits for pre-existing interrupt and NMI
2510 in one domain does not delay an SRCU grace period in some other domain.
2526 sections, then that domain's grace periods will also be blocked forever.
2529 section can wait, either directly or indirectly, for that domain's grace
2560 invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
2565 an SRCU grace period, that grace period is waiting on a timer, and that
2572 non-expedited grace periods are implemented by the same mechanism. This
2573 means that in the current SRCU implementation, expediting a future grace
2574 period has the side effect of expediting all prior grace periods that
2606 the completion of a future SRCU grace period and ensures
2607 that this grace period will be started.
2610 SRCU grace period.
2613 it does nothing to ensure that any future SRCU grace period
2616 These functions are used to avoid unnecessary SRCU grace periods in
2619 from the cache, an SRCU grace period will be very likely to have elapsed.
2693 increase grace-period latency with increasing numbers of CPUs. If this
2695 grace-period state machine so as to avoid the need for the additional
2704 The tradeoff between grace-period latency on the one hand and
2706 re-examined. The desire is of course for zero grace-period latency as
2708 grace period operation. While this ideal is unlikely to be achievable,
2742 guarantees under heavy load for grace periods and for callback