Lines Matching refs:grace
8 This document describes RCU's expedited grace periods.
9 Unlike RCU's normal grace periods, which accept long latencies to attain
10 high efficiency and minimal disturbance, expedited grace periods accept
20 The expedited RCU grace periods cannot be accused of being subtle,
23 grace period.
24 The one saving grace is that the hammer has grown a bit smaller
32 state, the expedited grace period has completed.
43 expedited grace period is shown in the following diagram:
54 Otherwise, the expedited grace period will use
72 block the current expedited grace period until it resumes and finds its
75 the CPU is no longer blocking the grace period.
86 | Why not just have the expedited grace period check the state of all |
116 the handling of a given CPU by an RCU-sched expedited grace period is
140 The expedited nature of expedited grace periods require a much tighter
142 grace periods. In addition, attempting to IPI offline CPUs will result
143 in splats, but failing to IPI online CPUs can result in too-short grace
146 The interaction between expedited grace periods and CPU hotplug
152 have ever been online at the beginning of an RCU expedited grace
159 beginning of the most recent RCU expedited grace period. The
163 field has changed since the beginning of the last RCU expedited grace
168 RCU expedited grace period. This means that only those CPUs that have
169 been online at least once will be considered for a given grace
177 grace period invokes ``smp_call_function_single()``. If this
198 | between grace-period initialization and CPU-hotplug operations. For |
203 | will result in grace-period hangs. In short, that way lies madness, |
206 | grace-period initialization will always see consistent masks up and |
214 | grace period greatly simplifies maintenance of the CPU-tracking |
224 Each expedited grace period checks for idle CPUs when initially forming
228 Instead, the task pushing the grace period forward will include the idle
244 In summary, RCU expedited grace periods check for idle when building the
251 If each grace-period request was carried out separately, expedited grace
253 characteristics. Because each grace-period operation can serve an
255 that a single expedited grace-period operation will cover all requests
260 has an odd value when there is an expedited grace period in progress and
262 the number of completed grace periods. During any given update request,
264 indicating that a grace period has elapsed. Therefore, if the initial
270 grace period.
271 #. ``rcu_exp_gp_seq_end()``, which marks the end of an expedited grace
275 grace period has elapsed since the corresponding call to
279 grace-period operation, which means there must be an efficient way to
280 identify which of many concurrent reqeusts will initiate the grace
282 wait for that grace period to complete. However, that is the topic of
289 the expedited grace period is to use the ``rcu_node`` combining tree, as
291 corresponding to a given grace period arriving at a given ``rcu_node``
292 structure records its desired grace-period sequence number in the
295 number for the desired grace period or some later one, the updater
317 Suppose that Task A wins, recording its desired grace-period sequence
322 Task A now advances to initiate a new grace period, while Task B moves
337 | whether or not a grace period is currently in progress. It is |
339 | position to obtain the number of the grace period. This results in |
344 desired grace-period sequence number, and see that both leaf
352 initiates the grace period, which increments ``->expedited_sequence``.
360 Task A to finish so that it can start the next grace period. The
365 Once the grace period completes, Task A starts waking up the tasks
366 waiting for this grace period to complete, increments the
385 Execution will continue with Tasks E and H completing their grace
392 | grace period completes? |
398 | the next grace period from starting. This last is important in |
405 In earlier implementations, the task requesting the expedited grace
414 workqueue kthread does the actual grace-period processing. Because
415 workqueue kthreads do not accept POSIX signals, grace-period-wait
417 allows wakeups for the previous expedited grace period to be overlapped
418 with processing for the next expedited grace period. Because there are
420 previous grace period's wakeups complete before the next grace period's
422 expedited grace-period processing and the ``->exp_wake_mutex`` guard
426 previous grace period's wakeups can be carried out while the current
427 grace period is in process, but that these wakeups will complete before
428 the next grace period starts. This means that only three waitqueues are
434 Expediting grace periods does nothing to speed things up when RCU
435 readers take too long, and therefore expedited grace periods check for
436 stalls just as normal grace periods do.
441 | But why not just let the normal grace-period machinery detect the |
443 | expedited grace periods? |
448 | grace period in progress, in which case the normal grace period |
453 the expedited grace period to end, but with a timeout set to the current
455 ``rcu_node`` structures blocking the current grace period are printed.
462 The use of workqueues has the advantage that the expedited grace-period
467 really do want to execute grace periods during this mid-boot “dead
468 zone”, expedited grace periods must do something else during thie time.
471 requesting task drive the expedited grace period, as was the case before
473 drive the grace period during the mid-boot dead zone. Before mid-boot, a
474 synchronous grace period is a no-op. Some time after mid-boot,
477 Non-expedited non-SRCU synchronous grace periods must also operate
478 normally during mid-boot. This is handled by causing non-expedited grace
488 With this refinement, synchronous grace periods can now be used from
496 Expedited grace periods use a sequence-number approach to promote
497 batching, so that a single grace-period operation can serve numerous
499 of a concurrent group that will request the grace period. All members of
501 structure. The actual grace-period processing is carried out by a
505 tight synchronization between expedited grace periods and CPU-hotplug
513 expedited grace period are awakened. A pair of mutexes are used to allow
514 one grace period's wakeups to proceed concurrently with the next grace
517 This combination of mechanisms allows expedited grace periods to run
519 grace periods should be used instead because their longer duration