Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst

23 grace period.
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
153    period. Note that this number never decreases, at least in the
159    beginning of the most recent RCU expedited grace period. The
164    period, which triggers an update of each ``rcu_node`` structure's
168    RCU expedited grace period. This means that only those CPUs that have
170    period.
177    grace period invokes ``smp_call_function_single()``. If this
180    necessary to wait for a short time period and try again. The purpose
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
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
264 indicating that a grace period has elapsed. Therefore, if the initial
270    grace period.
272    period.
275    grace period has elapsed since the corresponding call to
279 grace-period operation, which means there must be an efficient way to
281 period, and that there be an efficient way for the remaining requests to
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
392 | grace period completes?                                               |
398 | the next grace period from starting. This last is important in        |
406 period also drove it to completion. This straightforward approach had
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
441 | But why not just let the normal grace-period machinery detect the     |
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
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,
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
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
515 period's processing.