1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2 "http://www.w3.org/TR/html4/loose.dtd">
4 <head><title>A Tour Through TREE_RCU's Grace-Period Memory Ordering</title>
5 <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
8 <p>This article was contributed by Paul E. McKenney</p>
12 <p>This document gives a rough visual overview of how Tree RCU's
13 grace-period memory ordering guarantee is provided.
16 <li> <a href="#What Is Tree RCU's Grace Period Memory Ordering Guarantee?">
17 What Is Tree RCU's Grace Period Memory Ordering Guarantee?</a>
18 <li> <a href="#Tree RCU Grace Period Memory Ordering Building Blocks">
19 Tree RCU Grace Period Memory Ordering Building Blocks</a>
20 <li> <a href="#Tree RCU Grace Period Memory Ordering Components">
21 Tree RCU Grace Period Memory Ordering Components</a>
22 <li> <a href="#Putting It All Together">Putting It All Together</a>
25 <h3><a name="What Is Tree RCU's Grace Period Memory Ordering Guarantee?">
26 What Is Tree RCU's Grace Period Memory Ordering Guarantee?</a></h3>
28 <p>RCU grace periods provide extremely strong memory-ordering guarantees
29 for non-idle non-offline code.
30 Any code that happens after the end of a given RCU grace period is guaranteed
31 to see the effects of all accesses prior to the beginning of that grace
32 period that are within RCU read-side critical sections.
33 Similarly, any code that happens before the beginning of a given RCU grace
34 period is guaranteed to see the effects of all accesses following the end
35 of that grace period that are within RCU read-side critical sections.
37 <p>Note well that RCU-sched read-side critical sections include any region
38 of code for which preemption is disabled.
39 Given that each individual machine instruction can be thought of as
40 an extremely small region of preemption-disabled code, one can think of
41 <tt>synchronize_rcu()</tt> as <tt>smp_mb()</tt> on steroids.
43 <p>RCU updaters use this guarantee by splitting their updates into
44 two phases, one of which is executed before the grace period and
45 the other of which is executed after the grace period.
46 In the most common use case, phase one removes an element from
47 a linked RCU-protected data structure, and phase two frees that element.
48 For this to work, any readers that have witnessed state prior to the
49 phase-one update (in the common case, removal) must not witness state
50 following the phase-two update (in the common case, freeing).
52 <p>The RCU implementation provides this guarantee using a network
53 of lock-based critical sections, memory barriers, and per-CPU
54 processing, as is described in the following sections.
56 <h3><a name="Tree RCU Grace Period Memory Ordering Building Blocks">
57 Tree RCU Grace Period Memory Ordering Building Blocks</a></h3>
59 <p>The workhorse for RCU's grace-period memory ordering is the
60 critical section for the <tt>rcu_node</tt> structure's
62 These critical sections use helper functions for lock acquisition, including
63 <tt>raw_spin_lock_rcu_node()</tt>,
64 <tt>raw_spin_lock_irq_rcu_node()</tt>, and
65 <tt>raw_spin_lock_irqsave_rcu_node()</tt>.
66 Their lock-release counterparts are
67 <tt>raw_spin_unlock_rcu_node()</tt>,
68 <tt>raw_spin_unlock_irq_rcu_node()</tt>, and
69 <tt>raw_spin_unlock_irqrestore_rcu_node()</tt>,
72 <tt>raw_spin_trylock_rcu_node()</tt>
74 The key point is that the lock-acquisition functions, including
75 <tt>raw_spin_trylock_rcu_node()</tt>, all invoke
76 <tt>smp_mb__after_unlock_lock()</tt> immediately after successful
77 acquisition of the lock.
79 <p>Therefore, for any given <tt>rcu_node</tt> structure, any access
80 happening before one of the above lock-release functions will be seen
81 by all CPUs as happening before any access happening after a later
82 one of the above lock-acquisition functions.
83 Furthermore, any access happening before one of the
84 above lock-release function on any given CPU will be seen by all
85 CPUs as happening before any access happening after a later one
86 of the above lock-acquisition functions executing on that same CPU,
87 even if the lock-release and lock-acquisition functions are operating
88 on different <tt>rcu_node</tt> structures.
89 Tree RCU uses these two ordering guarantees to form an ordering
90 network among all CPUs that were in any way involved in the grace
91 period, including any CPUs that came online or went offline during
92 the grace period in question.
94 <p>The following litmus test exhibits the ordering effects of these
95 lock-acquisition and lock-release functions:
102 5 raw_spin_lock_rcu_node(rnp);
105 8 raw_spin_unlock_rcu_node(rnp);
110 13 raw_spin_lock_rcu_node(rnp);
112 15 r2 = READ_ONCE(z);
113 16 raw_spin_unlock_rcu_node(rnp);
120 23 r3 = READ_ONCE(x);
123 26 WARN_ON(r1 == 0 && r2 == 0 && r3 == 0);
126 <p>The <tt>WARN_ON()</tt> is evaluated at “the end of time”,
127 after all changes have propagated throughout the system.
128 Without the <tt>smp_mb__after_unlock_lock()</tt> provided by the
129 acquisition functions, this <tt>WARN_ON()</tt> could trigger, for example
131 The <tt>smp_mb__after_unlock_lock()</tt> invocations prevent this
132 <tt>WARN_ON()</tt> from triggering.
134 <p>This approach must be extended to include idle CPUs, which need
135 RCU's grace-period memory ordering guarantee to extend to any
136 RCU read-side critical sections preceding and following the current
138 This case is handled by calls to the strongly ordered
139 <tt>atomic_add_return()</tt> read-modify-write atomic operation that
140 is invoked within <tt>rcu_dynticks_eqs_enter()</tt> at idle-entry
141 time and within <tt>rcu_dynticks_eqs_exit()</tt> at idle-exit time.
142 The grace-period kthread invokes <tt>rcu_dynticks_snap()</tt> and
143 <tt>rcu_dynticks_in_eqs_since()</tt> (both of which invoke
144 an <tt>atomic_add_return()</tt> of zero) to detect idle CPUs.
147 <tr><th> </th></tr>
148 <tr><th align="left">Quick Quiz:</th></tr>
150 But what about CPUs that remain offline for the entire
153 <tr><th align="left">Answer:</th></tr>
154 <tr><td bgcolor="#ffffff"><font color="ffffff">
155 Such CPUs will be offline at the beginning of the grace period,
156 so the grace period won't expect quiescent states from them.
157 Races between grace-period start and CPU-hotplug operations
158 are mediated by the CPU's leaf <tt>rcu_node</tt> structure's
159 <tt>->lock</tt> as described above.
161 <tr><td> </td></tr>
164 <p>The approach must be extended to handle one final case, that
165 of waking a task blocked in <tt>synchronize_rcu()</tt>.
166 This task might be affinitied to a CPU that is not yet aware that
167 the grace period has ended, and thus might not yet be subject to
168 the grace period's memory ordering.
169 Therefore, there is an <tt>smp_mb()</tt> after the return from
170 <tt>wait_for_completion()</tt> in the <tt>synchronize_rcu()</tt>
174 <tr><th> </th></tr>
175 <tr><th align="left">Quick Quiz:</th></tr>
178 I don't see any <tt>smp_mb()</tt> after the return from
179 <tt>wait_for_completion()</tt>!!!
181 <tr><th align="left">Answer:</th></tr>
182 <tr><td bgcolor="#ffffff"><font color="ffffff">
183 That would be because I spotted the need for that
184 <tt>smp_mb()</tt> during the creation of this documentation,
185 and it is therefore unlikely to hit mainline before v4.14.
186 Kudos to Lance Roy, Will Deacon, Peter Zijlstra, and
187 Jonathan Cameron for asking questions that sensitized me
188 to the rather elaborate sequence of events that demonstrate
189 the need for this memory barrier.
191 <tr><td> </td></tr>
194 <p>Tree RCU's grace--period memory-ordering guarantees rely most
195 heavily on the <tt>rcu_node</tt> structure's <tt>->lock</tt>
196 field, so much so that it is necessary to abbreviate this pattern
197 in the diagrams in the next section.
198 For example, consider the <tt>rcu_prepare_for_idle()</tt> function
199 shown below, which is one of several functions that enforce ordering
200 of newly arrived RCU callbacks against future grace periods:
203 1 static void rcu_prepare_for_idle(void)
206 4 struct rcu_data *rdp;
207 5 struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
208 6 struct rcu_node *rnp;
209 7 struct rcu_state *rsp;
212 10 if (IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL) ||
213 11 rcu_is_nocb_cpu(smp_processor_id()))
215 13 tne = READ_ONCE(tick_nohz_active);
216 14 if (tne != rdtp->tick_nohz_enabled_snap) {
217 15 if (rcu_cpu_has_callbacks(NULL))
218 16 invoke_rcu_core();
219 17 rdtp->tick_nohz_enabled_snap = tne;
224 22 if (rdtp->all_lazy &&
225 23 rdtp->nonlazy_posted != rdtp->nonlazy_posted_snap) {
226 24 rdtp->all_lazy = false;
227 25 rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted;
228 26 invoke_rcu_core();
231 29 if (rdtp->last_accelerate == jiffies)
233 31 rdtp->last_accelerate = jiffies;
234 32 for_each_rcu_flavor(rsp) {
235 33 rdp = this_cpu_ptr(rsp->rda);
236 34 if (rcu_segcblist_pend_cbs(&rdp->cblist))
238 36 rnp = rdp->mynode;
239 37 raw_spin_lock_rcu_node(rnp);
240 38 needwake = rcu_accelerate_cbs(rsp, rnp, rdp);
241 39 raw_spin_unlock_rcu_node(rnp);
243 41 rcu_gp_kthread_wake(rsp);
248 <p>But the only part of <tt>rcu_prepare_for_idle()</tt> that really
249 matters for this discussion are lines 37–39.
250 We will therefore abbreviate this function as follows:
252 </p><p><img src="rcu_node-lock.svg" alt="rcu_node-lock.svg">
254 <p>The box represents the <tt>rcu_node</tt> structure's <tt>->lock</tt>
255 critical section, with the double line on top representing the additional
256 <tt>smp_mb__after_unlock_lock()</tt>.
258 <h3><a name="Tree RCU Grace Period Memory Ordering Components">
259 Tree RCU Grace Period Memory Ordering Components</a></h3>
261 <p>Tree RCU's grace-period memory-ordering guarantee is provided by
262 a number of RCU components:
265 <li> <a href="#Callback Registry">Callback Registry</a>
266 <li> <a href="#Grace-Period Initialization">Grace-Period Initialization</a>
267 <li> <a href="#Self-Reported Quiescent States">
268 Self-Reported Quiescent States</a>
269 <li> <a href="#Dynamic Tick Interface">Dynamic Tick Interface</a>
270 <li> <a href="#CPU-Hotplug Interface">CPU-Hotplug Interface</a>
271 <li> <a href="Forcing Quiescent States">Forcing Quiescent States</a>
272 <li> <a href="Grace-Period Cleanup">Grace-Period Cleanup</a>
273 <li> <a href="Callback Invocation">Callback Invocation</a>
276 <p>Each of the following section looks at the corresponding component
279 <h4><a name="Callback Registry">Callback Registry</a></h4>
281 <p>If RCU's grace-period guarantee is to mean anything at all, any
282 access that happens before a given invocation of <tt>call_rcu()</tt>
283 must also happen before the corresponding grace period.
284 The implementation of this portion of RCU's grace period guarantee
285 is shown in the following figure:
287 </p><p><img src="TreeRCU-callback-registry.svg" alt="TreeRCU-callback-registry.svg">
289 <p>Because <tt>call_rcu()</tt> normally acts only on CPU-local state,
290 it provides no ordering guarantees, either for itself or for
291 phase one of the update (which again will usually be removal of
292 an element from an RCU-protected data structure).
293 It simply enqueues the <tt>rcu_head</tt> structure on a per-CPU list,
294 which cannot become associated with a grace period until a later
295 call to <tt>rcu_accelerate_cbs()</tt>, as shown in the diagram above.
297 <p>One set of code paths shown on the left invokes
298 <tt>rcu_accelerate_cbs()</tt> via
299 <tt>note_gp_changes()</tt>, either directly from <tt>call_rcu()</tt> (if
300 the current CPU is inundated with queued <tt>rcu_head</tt> structures)
301 or more likely from an <tt>RCU_SOFTIRQ</tt> handler.
302 Another code path in the middle is taken only in kernels built with
303 <tt>CONFIG_RCU_FAST_NO_HZ=y</tt>, which invokes
304 <tt>rcu_accelerate_cbs()</tt> via <tt>rcu_prepare_for_idle()</tt>.
305 The final code path on the right is taken only in kernels built with
306 <tt>CONFIG_HOTPLUG_CPU=y</tt>, which invokes
307 <tt>rcu_accelerate_cbs()</tt> via
308 <tt>rcu_advance_cbs()</tt>, <tt>rcu_migrate_callbacks</tt>,
309 <tt>rcutree_migrate_callbacks()</tt>, and <tt>takedown_cpu()</tt>,
310 which in turn is invoked on a surviving CPU after the outgoing
311 CPU has been completely offlined.
313 <p>There are a few other code paths within grace-period processing
314 that opportunistically invoke <tt>rcu_accelerate_cbs()</tt>.
315 However, either way, all of the CPU's recently queued <tt>rcu_head</tt>
316 structures are associated with a future grace-period number under
317 the protection of the CPU's lead <tt>rcu_node</tt> structure's
319 In all cases, there is full ordering against any prior critical section
320 for that same <tt>rcu_node</tt> structure's <tt>->lock</tt>, and
321 also full ordering against any of the current task's or CPU's prior critical
322 sections for any <tt>rcu_node</tt> structure's <tt>->lock</tt>.
324 <p>The next section will show how this ordering ensures that any
325 accesses prior to the <tt>call_rcu()</tt> (particularly including phase
327 happen before the start of the corresponding grace period.
330 <tr><th> </th></tr>
331 <tr><th align="left">Quick Quiz:</th></tr>
333 But what about <tt>synchronize_rcu()</tt>?
335 <tr><th align="left">Answer:</th></tr>
336 <tr><td bgcolor="#ffffff"><font color="ffffff">
337 The <tt>synchronize_rcu()</tt> passes <tt>call_rcu()</tt>
338 to <tt>wait_rcu_gp()</tt>, which invokes it.
339 So either way, it eventually comes down to <tt>call_rcu()</tt>.
341 <tr><td> </td></tr>
344 <h4><a name="Grace-Period Initialization">Grace-Period Initialization</a></h4>
346 <p>Grace-period initialization is carried out by
347 the grace-period kernel thread, which makes several passes over the
348 <tt>rcu_node</tt> tree within the <tt>rcu_gp_init()</tt> function.
349 This means that showing the full flow of ordering through the
350 grace-period computation will require duplicating this tree.
351 If you find this confusing, please note that the state of the
352 <tt>rcu_node</tt> changes over time, just like Heraclitus's river.
353 However, to keep the <tt>rcu_node</tt> river tractable, the
354 grace-period kernel thread's traversals are presented in multiple
355 parts, starting in this section with the various phases of
356 grace-period initialization.
358 <p>The first ordering-related grace-period initialization action is to
359 advance the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt>
360 grace-period-number counter, as shown below:
362 </p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
364 <p>The actual increment is carried out using <tt>smp_store_release()</tt>,
365 which helps reject false-positive RCU CPU stall detection.
366 Note that only the root <tt>rcu_node</tt> structure is touched.
368 <p>The first pass through the <tt>rcu_node</tt> tree updates bitmasks
369 based on CPUs having come online or gone offline since the start of
370 the previous grace period.
371 In the common case where the number of online CPUs for this <tt>rcu_node</tt>
372 structure has not transitioned to or from zero,
373 this pass will scan only the leaf <tt>rcu_node</tt> structures.
374 However, if the number of online CPUs for a given leaf <tt>rcu_node</tt>
375 structure has transitioned from zero,
376 <tt>rcu_init_new_rnp()</tt> will be invoked for the first incoming CPU.
377 Similarly, if the number of online CPUs for a given leaf <tt>rcu_node</tt>
378 structure has transitioned to zero,
379 <tt>rcu_cleanup_dead_rnp()</tt> will be invoked for the last outgoing CPU.
380 The diagram below shows the path of ordering if the leftmost
381 <tt>rcu_node</tt> structure onlines its first CPU and if the next
382 <tt>rcu_node</tt> structure has no online CPUs
383 (or, alternatively if the leftmost <tt>rcu_node</tt> structure offlines
384 its last CPU and if the next <tt>rcu_node</tt> structure has no online CPUs).
386 </p><p><img src="TreeRCU-gp-init-2.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
388 <p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>
389 tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
390 <tt>->gp_seq</tt> field to the newly advanced value from the
391 <tt>rcu_state</tt> structure, as shown in the following diagram.
393 </p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
395 <p>This change will also cause each CPU's next call to
396 <tt>__note_gp_changes()</tt>
397 to notice that a new grace period has started, as described in the next
399 But because the grace-period kthread started the grace period at the
400 root (with the advancing of the <tt>rcu_state</tt> structure's
401 <tt>->gp_seq</tt> field) before setting each leaf <tt>rcu_node</tt>
402 structure's <tt>->gp_seq</tt> field, each CPU's observation of
403 the start of the grace period will happen after the actual start
407 <tr><th> </th></tr>
408 <tr><th align="left">Quick Quiz:</th></tr>
410 But what about the CPU that started the grace period?
411 Why wouldn't it see the start of the grace period right when
412 it started that grace period?
414 <tr><th align="left">Answer:</th></tr>
415 <tr><td bgcolor="#ffffff"><font color="ffffff">
416 In some deep philosophical and overly anthromorphized
417 sense, yes, the CPU starting the grace period is immediately
418 aware of having done so.
419 However, if we instead assume that RCU is not self-aware,
420 then even the CPU starting the grace period does not really
421 become aware of the start of this grace period until its
422 first call to <tt>__note_gp_changes()</tt>.
423 On the other hand, this CPU potentially gets early notification
424 because it invokes <tt>__note_gp_changes()</tt> during its
425 last <tt>rcu_gp_init()</tt> pass through its leaf
426 <tt>rcu_node</tt> structure.
428 <tr><td> </td></tr>
431 <h4><a name="Self-Reported Quiescent States">
432 Self-Reported Quiescent States</a></h4>
434 <p>When all entities that might block the grace period have reported
435 quiescent states (or as described in a later section, had quiescent
436 states reported on their behalf), the grace period can end.
437 Online non-idle CPUs report their own quiescent states, as shown
438 in the following diagram:
440 </p><p><img src="TreeRCU-qs.svg" alt="TreeRCU-qs.svg" width="75%">
442 <p>This is for the last CPU to report a quiescent state, which signals
443 the end of the grace period.
444 Earlier quiescent states would push up the <tt>rcu_node</tt> tree
445 only until they encountered an <tt>rcu_node</tt> structure that
446 is waiting for additional quiescent states.
447 However, ordering is nevertheless preserved because some later quiescent
448 state will acquire that <tt>rcu_node</tt> structure's <tt>->lock</tt>.
450 <p>Any number of events can lead up to a CPU invoking
451 <tt>note_gp_changes</tt> (or alternatively, directly invoking
452 <tt>__note_gp_changes()</tt>), at which point that CPU will notice
453 the start of a new grace period while holding its leaf
454 <tt>rcu_node</tt> lock.
455 Therefore, all execution shown in this diagram happens after the
456 start of the grace period.
457 In addition, this CPU will consider any RCU read-side critical
458 section that started before the invocation of <tt>__note_gp_changes()</tt>
459 to have started before the grace period, and thus a critical
460 section that the grace period must wait on.
463 <tr><th> </th></tr>
464 <tr><th align="left">Quick Quiz:</th></tr>
466 But a RCU read-side critical section might have started
467 after the beginning of the grace period
468 (the advancing of <tt>->gp_seq</tt> from earlier), so why should
469 the grace period wait on such a critical section?
471 <tr><th align="left">Answer:</th></tr>
472 <tr><td bgcolor="#ffffff"><font color="ffffff">
473 It is indeed not necessary for the grace period to wait on such
475 However, it is permissible to wait on it.
476 And it is furthermore important to wait on it, as this
477 lazy approach is far more scalable than a “big bang”
478 all-at-once grace-period start could possibly be.
480 <tr><td> </td></tr>
483 <p>If the CPU does a context switch, a quiescent state will be
484 noted by <tt>rcu_node_context_switch()</tt> on the left.
485 On the other hand, if the CPU takes a scheduler-clock interrupt
486 while executing in usermode, a quiescent state will be noted by
487 <tt>rcu_sched_clock_irq()</tt> on the right.
488 Either way, the passage through a quiescent state will be noted
489 in a per-CPU variable.
491 <p>The next time an <tt>RCU_SOFTIRQ</tt> handler executes on
492 this CPU (for example, after the next scheduler-clock
493 interrupt), <tt>rcu_core()</tt> will invoke
494 <tt>rcu_check_quiescent_state()</tt>, which will notice the
495 recorded quiescent state, and invoke
496 <tt>rcu_report_qs_rdp()</tt>.
497 If <tt>rcu_report_qs_rdp()</tt> verifies that the quiescent state
498 really does apply to the current grace period, it invokes
499 <tt>rcu_report_rnp()</tt> which traverses up the <tt>rcu_node</tt>
500 tree as shown at the bottom of the diagram, clearing bits from
501 each <tt>rcu_node</tt> structure's <tt>->qsmask</tt> field,
502 and propagating up the tree when the result is zero.
504 <p>Note that traversal passes upwards out of a given <tt>rcu_node</tt>
505 structure only if the current CPU is reporting the last quiescent
506 state for the subtree headed by that <tt>rcu_node</tt> structure.
507 A key point is that if a CPU's traversal stops at a given <tt>rcu_node</tt>
508 structure, then there will be a later traversal by another CPU
509 (or perhaps the same one) that proceeds upwards
510 from that point, and the <tt>rcu_node</tt> <tt>->lock</tt>
511 guarantees that the first CPU's quiescent state happens before the
512 remainder of the second CPU's traversal.
513 Applying this line of thought repeatedly shows that all CPUs'
514 quiescent states happen before the last CPU traverses through
515 the root <tt>rcu_node</tt> structure, the “last CPU”
516 being the one that clears the last bit in the root <tt>rcu_node</tt>
517 structure's <tt>->qsmask</tt> field.
519 <h4><a name="Dynamic Tick Interface">Dynamic Tick Interface</a></h4>
521 <p>Due to energy-efficiency considerations, RCU is forbidden from
522 disturbing idle CPUs.
523 CPUs are therefore required to notify RCU when entering or leaving idle
524 state, which they do via fully ordered value-returning atomic operations
525 on a per-CPU variable.
526 The ordering effects are as shown below:
528 </p><p><img src="TreeRCU-dyntick.svg" alt="TreeRCU-dyntick.svg" width="50%">
530 <p>The RCU grace-period kernel thread samples the per-CPU idleness
531 variable while holding the corresponding CPU's leaf <tt>rcu_node</tt>
532 structure's <tt>->lock</tt>.
533 This means that any RCU read-side critical sections that precede the
534 idle period (the oval near the top of the diagram above) will happen
535 before the end of the current grace period.
536 Similarly, the beginning of the current grace period will happen before
537 any RCU read-side critical sections that follow the
538 idle period (the oval near the bottom of the diagram above).
540 <p>Plumbing this into the full grace-period execution is described
541 <a href="#Forcing Quiescent States">below</a>.
543 <h4><a name="CPU-Hotplug Interface">CPU-Hotplug Interface</a></h4>
545 <p>RCU is also forbidden from disturbing offline CPUs, which might well
546 be powered off and removed from the system completely.
547 CPUs are therefore required to notify RCU of their comings and goings
548 as part of the corresponding CPU hotplug operations.
549 The ordering effects are shown below:
551 </p><p><img src="TreeRCU-hotplug.svg" alt="TreeRCU-hotplug.svg" width="50%">
553 <p>Because CPU hotplug operations are much less frequent than idle transitions,
554 they are heavier weight, and thus acquire the CPU's leaf <tt>rcu_node</tt>
555 structure's <tt>->lock</tt> and update this structure's
556 <tt>->qsmaskinitnext</tt>.
557 The RCU grace-period kernel thread samples this mask to detect CPUs
558 having gone offline since the beginning of this grace period.
560 <p>Plumbing this into the full grace-period execution is described
561 <a href="#Forcing Quiescent States">below</a>.
563 <h4><a name="Forcing Quiescent States">Forcing Quiescent States</a></h4>
565 <p>As noted above, idle and offline CPUs cannot report their own
566 quiescent states, and therefore the grace-period kernel thread
567 must do the reporting on their behalf.
568 This process is called “forcing quiescent states”, it is
569 repeated every few jiffies, and its ordering effects are shown below:
571 </p><p><img src="TreeRCU-gp-fqs.svg" alt="TreeRCU-gp-fqs.svg" width="100%">
573 <p>Each pass of quiescent state forcing is guaranteed to traverse the
574 leaf <tt>rcu_node</tt> structures, and if there are no new quiescent
575 states due to recently idled and/or offlined CPUs, then only the
576 leaves are traversed.
577 However, if there is a newly offlined CPU as illustrated on the left
578 or a newly idled CPU as illustrated on the right, the corresponding
579 quiescent state will be driven up towards the root.
580 As with self-reported quiescent states, the upwards driving stops
581 once it reaches an <tt>rcu_node</tt> structure that has quiescent
582 states outstanding from other CPUs.
585 <tr><th> </th></tr>
586 <tr><th align="left">Quick Quiz:</th></tr>
588 The leftmost drive to root stopped before it reached
589 the root <tt>rcu_node</tt> structure, which means that
590 there are still CPUs subordinate to that structure on
591 which the current grace period is waiting.
592 Given that, how is it possible that the rightmost drive
593 to root ended the grace period?
595 <tr><th align="left">Answer:</th></tr>
596 <tr><td bgcolor="#ffffff"><font color="ffffff">
598 It is in fact impossible in the absence of bugs in RCU.
599 But this diagram is complex enough as it is, so simplicity
601 You can think of it as poetic license, or you can think of
602 it as misdirection that is resolved in the
603 <a href="#Putting It All Together">stitched-together diagram</a>.
605 <tr><td> </td></tr>
608 <h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>
610 <p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree
611 breadth-first advancing all the <tt>->gp_seq</tt> fields, then it
612 advances the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt> field.
613 The ordering effects are shown below:
615 </p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">
617 <p>As indicated by the oval at the bottom of the diagram, once
618 grace-period cleanup is complete, the next grace period can begin.
621 <tr><th> </th></tr>
622 <tr><th align="left">Quick Quiz:</th></tr>
624 But when precisely does the grace period end?
626 <tr><th align="left">Answer:</th></tr>
627 <tr><td bgcolor="#ffffff"><font color="ffffff">
628 There is no useful single point at which the grace period
630 The earliest reasonable candidate is as soon as the last
631 CPU has reported its quiescent state, but it may be some
632 milliseconds before RCU becomes aware of this.
633 The latest reasonable candidate is once the <tt>rcu_state</tt>
634 structure's <tt>->gp_seq</tt> field has been updated,
635 but it is quite possible that some CPUs have already completed
636 phase two of their updates by that time.
637 In short, if you are going to work with RCU, you need to
638 learn to embrace uncertainty.
640 <tr><td> </td></tr>
644 <h4><a name="Callback Invocation">Callback Invocation</a></h4>
646 <p>Once a given CPU's leaf <tt>rcu_node</tt> structure's
647 <tt>->gp_seq</tt> field has been updated, that CPU can begin
648 invoking its RCU callbacks that were waiting for this grace period
650 These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
651 which is usually invoked by <tt>__note_gp_changes()</tt>.
652 As shown in the diagram below, this invocation can be triggered by
653 the scheduling-clock interrupt (<tt>rcu_sched_clock_irq()</tt> on
654 the left) or by idle entry (<tt>rcu_cleanup_after_idle()</tt> on
655 the right, but only for kernels build with
656 <tt>CONFIG_RCU_FAST_NO_HZ=y</tt>).
657 Either way, <tt>RCU_SOFTIRQ</tt> is raised, which results in
658 <tt>rcu_do_batch()</tt> invoking the callbacks, which in turn
659 allows those callbacks to carry out (either directly or indirectly
660 via wakeup) the needed phase-two processing for each update.
662 </p><p><img src="TreeRCU-callback-invocation.svg" alt="TreeRCU-callback-invocation.svg" width="60%">
664 <p>Please note that callback invocation can also be prompted by any
665 number of corner-case code paths, for example, when a CPU notes that
666 it has excessive numbers of callbacks queued.
667 In all cases, the CPU acquires its leaf <tt>rcu_node</tt> structure's
668 <tt>->lock</tt> before invoking callbacks, which preserves the
669 required ordering against the newly completed grace period.
671 <p>However, if the callback function communicates to other CPUs,
672 for example, doing a wakeup, then it is that function's responsibility
673 to maintain ordering.
674 For example, if the callback function wakes up a task that runs on
675 some other CPU, proper ordering must in place in both the callback
676 function and the task being awakened.
677 To see why this is important, consider the top half of the
678 <a href="#Grace-Period Cleanup">grace-period cleanup</a> diagram.
679 The callback might be running on a CPU corresponding to the leftmost
680 leaf <tt>rcu_node</tt> structure, and awaken a task that is to run on
681 a CPU corresponding to the rightmost leaf <tt>rcu_node</tt> structure,
682 and the grace-period kernel thread might not yet have reached the
684 In this case, the grace period's memory ordering might not yet have
685 reached that CPU, so again the callback function and the awakened
686 task must supply proper ordering.
688 <h3><a name="Putting It All Together">Putting It All Together</a></h3>
690 <p>A stitched-together diagram is
691 <a href="Tree-RCU-Diagram.html">here</a>.
693 <h3><a name="Legal Statement">
694 Legal Statement</a></h3>
696 <p>This work represents the view of the author and does not necessarily
697 represent the view of IBM.
699 </p><p>Linux is a registered trademark of Linus Torvalds.
701 </p><p>Other company, product, and service names may be trademarks or
702 service marks of others.