Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tjh.dev
kernel
os
linux
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2 "http://www.w3.org/TR/html4/loose.dtd">
3 <html>
4 <head><title>A Tour Through TREE_RCU's Data Structures [LWN.net]</title>
5 <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
6
7 <p>December 18, 2016</p>
8 <p>This article was contributed by Paul E. McKenney</p>
9
10<h3>Introduction</h3>
11
12This document describes RCU's major data structures and their relationship
13to each other.
14
15<ol>
16<li> <a href="#Data-Structure Relationships">
17 Data-Structure Relationships</a>
18<li> <a href="#The rcu_state Structure">
19 The <tt>rcu_state</tt> Structure</a>
20<li> <a href="#The rcu_node Structure">
21 The <tt>rcu_node</tt> Structure</a>
22<li> <a href="#The rcu_segcblist Structure">
23 The <tt>rcu_segcblist</tt> Structure</a>
24<li> <a href="#The rcu_data Structure">
25 The <tt>rcu_data</tt> Structure</a>
26<li> <a href="#The rcu_head Structure">
27 The <tt>rcu_head</tt> Structure</a>
28<li> <a href="#RCU-Specific Fields in the task_struct Structure">
29 RCU-Specific Fields in the <tt>task_struct</tt> Structure</a>
30<li> <a href="#Accessor Functions">
31 Accessor Functions</a>
32</ol>
33
34<h3><a name="Data-Structure Relationships">Data-Structure Relationships</a></h3>
35
36<p>RCU is for all intents and purposes a large state machine, and its
37data structures maintain the state in such a way as to allow RCU readers
38to execute extremely quickly, while also processing the RCU grace periods
39requested by updaters in an efficient and extremely scalable fashion.
40The efficiency and scalability of RCU updaters is provided primarily
41by a combining tree, as shown below:
42
43</p><p><img src="BigTreeClassicRCU.svg" alt="BigTreeClassicRCU.svg" width="30%">
44
45</p><p>This diagram shows an enclosing <tt>rcu_state</tt> structure
46containing a tree of <tt>rcu_node</tt> structures.
47Each leaf node of the <tt>rcu_node</tt> tree has up to 16
48<tt>rcu_data</tt> structures associated with it, so that there
49are <tt>NR_CPUS</tt> number of <tt>rcu_data</tt> structures,
50one for each possible CPU.
51This structure is adjusted at boot time, if needed, to handle the
52common case where <tt>nr_cpu_ids</tt> is much less than
53<tt>NR_CPUs</tt>.
54For example, a number of Linux distributions set <tt>NR_CPUs=4096</tt>,
55which results in a three-level <tt>rcu_node</tt> tree.
56If the actual hardware has only 16 CPUs, RCU will adjust itself
57at boot time, resulting in an <tt>rcu_node</tt> tree with only a single node.
58
59</p><p>The purpose of this combining tree is to allow per-CPU events
60such as quiescent states, dyntick-idle transitions,
61and CPU hotplug operations to be processed efficiently
62and scalably.
63Quiescent states are recorded by the per-CPU <tt>rcu_data</tt> structures,
64and other events are recorded by the leaf-level <tt>rcu_node</tt>
65structures.
66All of these events are combined at each level of the tree until finally
67grace periods are completed at the tree's root <tt>rcu_node</tt>
68structure.
69A grace period can be completed at the root once every CPU
70(or, in the case of <tt>CONFIG_PREEMPT_RCU</tt>, task)
71has passed through a quiescent state.
72Once a grace period has completed, record of that fact is propagated
73back down the tree.
74
75</p><p>As can be seen from the diagram, on a 64-bit system
76a two-level tree with 64 leaves can accommodate 1,024 CPUs, with a fanout
77of 64 at the root and a fanout of 16 at the leaves.
78
79<table>
80<tr><th> </th></tr>
81<tr><th align="left">Quick Quiz:</th></tr>
82<tr><td>
83 Why isn't the fanout at the leaves also 64?
84</td></tr>
85<tr><th align="left">Answer:</th></tr>
86<tr><td bgcolor="#ffffff"><font color="ffffff">
87 Because there are more types of events that affect the leaf-level
88 <tt>rcu_node</tt> structures than further up the tree.
89 Therefore, if the leaf <tt>rcu_node</tt> structures have fanout of
90 64, the contention on these structures' <tt>->structures</tt>
91 becomes excessive.
92 Experimentation on a wide variety of systems has shown that a fanout
93 of 16 works well for the leaves of the <tt>rcu_node</tt> tree.
94 </font>
95
96 <p><font color="ffffff">Of course, further experience with
97 systems having hundreds or thousands of CPUs may demonstrate
98 that the fanout for the non-leaf <tt>rcu_node</tt> structures
99 must also be reduced.
100 Such reduction can be easily carried out when and if it proves
101 necessary.
102 In the meantime, if you are using such a system and running into
103 contention problems on the non-leaf <tt>rcu_node</tt> structures,
104 you may use the <tt>CONFIG_RCU_FANOUT</tt> kernel configuration
105 parameter to reduce the non-leaf fanout as needed.
106 </font>
107
108 <p><font color="ffffff">Kernels built for systems with
109 strong NUMA characteristics might also need to adjust
110 <tt>CONFIG_RCU_FANOUT</tt> so that the domains of the
111 <tt>rcu_node</tt> structures align with hardware boundaries.
112 However, there has thus far been no need for this.
113</font></td></tr>
114<tr><td> </td></tr>
115</table>
116
117<p>If your system has more than 1,024 CPUs (or more than 512 CPUs on
118a 32-bit system), then RCU will automatically add more levels to the
119tree.
120For example, if you are crazy enough to build a 64-bit system with 65,536
121CPUs, RCU would configure the <tt>rcu_node</tt> tree as follows:
122
123</p><p><img src="HugeTreeClassicRCU.svg" alt="HugeTreeClassicRCU.svg" width="50%">
124
125</p><p>RCU currently permits up to a four-level tree, which on a 64-bit system
126accommodates up to 4,194,304 CPUs, though only a mere 524,288 CPUs for
12732-bit systems.
128On the other hand, you can set both <tt>CONFIG_RCU_FANOUT</tt> and
129<tt>CONFIG_RCU_FANOUT_LEAF</tt> to be as small as 2, which would result
130in a 16-CPU test using a 4-level tree.
131This can be useful for testing large-system capabilities on small test
132machines.
133
134</p><p>This multi-level combining tree allows us to get most of the
135performance and scalability
136benefits of partitioning, even though RCU grace-period detection is
137inherently a global operation.
138The trick here is that only the last CPU to report a quiescent state
139into a given <tt>rcu_node</tt> structure need advance to the <tt>rcu_node</tt>
140structure at the next level up the tree.
141This means that at the leaf-level <tt>rcu_node</tt> structure, only
142one access out of sixteen will progress up the tree.
143For the internal <tt>rcu_node</tt> structures, the situation is even
144more extreme: Only one access out of sixty-four will progress up
145the tree.
146Because the vast majority of the CPUs do not progress up the tree,
147the lock contention remains roughly constant up the tree.
148No matter how many CPUs there are in the system, at most 64 quiescent-state
149reports per grace period will progress all the way to the root
150<tt>rcu_node</tt> structure, thus ensuring that the lock contention
151on that root <tt>rcu_node</tt> structure remains acceptably low.
152
153</p><p>In effect, the combining tree acts like a big shock absorber,
154keeping lock contention under control at all tree levels regardless
155of the level of loading on the system.
156
157</p><p>RCU updaters wait for normal grace periods by registering
158RCU callbacks, either directly via <tt>call_rcu()</tt> and
159friends (namely <tt>call_rcu_bh()</tt> and <tt>call_rcu_sched()</tt>),
160or indirectly via <tt>synchronize_rcu()</tt> and friends.
161RCU callbacks are represented by <tt>rcu_head</tt> structures,
162which are queued on <tt>rcu_data</tt> structures while they are
163waiting for a grace period to elapse, as shown in the following figure:
164
165</p><p><img src="BigTreePreemptRCUBHdyntickCB.svg" alt="BigTreePreemptRCUBHdyntickCB.svg" width="40%">
166
167</p><p>This figure shows how <tt>TREE_RCU</tt>'s and
168<tt>PREEMPT_RCU</tt>'s major data structures are related.
169Lesser data structures will be introduced with the algorithms that
170make use of them.
171
172</p><p>Note that each of the data structures in the above figure has
173its own synchronization:
174
175<p><ol>
176<li> Each <tt>rcu_state</tt> structures has a lock and a mutex,
177 and some fields are protected by the corresponding root
178 <tt>rcu_node</tt> structure's lock.
179<li> Each <tt>rcu_node</tt> structure has a spinlock.
180<li> The fields in <tt>rcu_data</tt> are private to the corresponding
181 CPU, although a few can be read and written by other CPUs.
182</ol>
183
184<p>It is important to note that different data structures can have
185very different ideas about the state of RCU at any given time.
186For but one example, awareness of the start or end of a given RCU
187grace period propagates slowly through the data structures.
188This slow propagation is absolutely necessary for RCU to have good
189read-side performance.
190If this balkanized implementation seems foreign to you, one useful
191trick is to consider each instance of these data structures to be
192a different person, each having the usual slightly different
193view of reality.
194
195</p><p>The general role of each of these data structures is as
196follows:
197
198</p><ol>
199<li> <tt>rcu_state</tt>:
200 This structure forms the interconnection between the
201 <tt>rcu_node</tt> and <tt>rcu_data</tt> structures,
202 tracks grace periods, serves as short-term repository
203 for callbacks orphaned by CPU-hotplug events,
204 maintains <tt>rcu_barrier()</tt> state,
205 tracks expedited grace-period state,
206 and maintains state used to force quiescent states when
207 grace periods extend too long,
208<li> <tt>rcu_node</tt>: This structure forms the combining
209 tree that propagates quiescent-state
210 information from the leaves to the root, and also propagates
211 grace-period information from the root to the leaves.
212 It provides local copies of the grace-period state in order
213 to allow this information to be accessed in a synchronized
214 manner without suffering the scalability limitations that
215 would otherwise be imposed by global locking.
216 In <tt>CONFIG_PREEMPT_RCU</tt> kernels, it manages the lists
217 of tasks that have blocked while in their current
218 RCU read-side critical section.
219 In <tt>CONFIG_PREEMPT_RCU</tt> with
220 <tt>CONFIG_RCU_BOOST</tt>, it manages the
221 per-<tt>rcu_node</tt> priority-boosting
222 kernel threads (kthreads) and state.
223 Finally, it records CPU-hotplug state in order to determine
224 which CPUs should be ignored during a given grace period.
225<li> <tt>rcu_data</tt>: This per-CPU structure is the
226 focus of quiescent-state detection and RCU callback queuing.
227 It also tracks its relationship to the corresponding leaf
228 <tt>rcu_node</tt> structure to allow more-efficient
229 propagation of quiescent states up the <tt>rcu_node</tt>
230 combining tree.
231 Like the <tt>rcu_node</tt> structure, it provides a local
232 copy of the grace-period information to allow for-free
233 synchronized
234 access to this information from the corresponding CPU.
235 Finally, this structure records past dyntick-idle state
236 for the corresponding CPU and also tracks statistics.
237<li> <tt>rcu_head</tt>:
238 This structure represents RCU callbacks, and is the
239 only structure allocated and managed by RCU users.
240 The <tt>rcu_head</tt> structure is normally embedded
241 within the RCU-protected data structure.
242</ol>
243
244<p>If all you wanted from this article was a general notion of how
245RCU's data structures are related, you are done.
246Otherwise, each of the following sections give more details on
247the <tt>rcu_state</tt>, <tt>rcu_node</tt> and <tt>rcu_data</tt> data
248structures.
249
250<h3><a name="The rcu_state Structure">
251The <tt>rcu_state</tt> Structure</a></h3>
252
253<p>The <tt>rcu_state</tt> structure is the base structure that
254represents the state of RCU in the system.
255This structure forms the interconnection between the
256<tt>rcu_node</tt> and <tt>rcu_data</tt> structures,
257tracks grace periods, contains the lock used to
258synchronize with CPU-hotplug events,
259and maintains state used to force quiescent states when
260grace periods extend too long,
261
262</p><p>A few of the <tt>rcu_state</tt> structure's fields are discussed,
263singly and in groups, in the following sections.
264The more specialized fields are covered in the discussion of their
265use.
266
267<h5>Relationship to rcu_node and rcu_data Structures</h5>
268
269This portion of the <tt>rcu_state</tt> structure is declared
270as follows:
271
272<pre>
273 1 struct rcu_node node[NUM_RCU_NODES];
274 2 struct rcu_node *level[NUM_RCU_LVLS + 1];
275 3 struct rcu_data __percpu *rda;
276</pre>
277
278<table>
279<tr><th> </th></tr>
280<tr><th align="left">Quick Quiz:</th></tr>
281<tr><td>
282 Wait a minute!
283 You said that the <tt>rcu_node</tt> structures formed a tree,
284 but they are declared as a flat array!
285 What gives?
286</td></tr>
287<tr><th align="left">Answer:</th></tr>
288<tr><td bgcolor="#ffffff"><font color="ffffff">
289 The tree is laid out in the array.
290 The first node In the array is the head, the next set of nodes in the
291 array are children of the head node, and so on until the last set of
292 nodes in the array are the leaves.
293 </font>
294
295 <p><font color="ffffff">See the following diagrams to see how
296 this works.
297</font></td></tr>
298<tr><td> </td></tr>
299</table>
300
301<p>The <tt>rcu_node</tt> tree is embedded into the
302<tt>->node[]</tt> array as shown in the following figure:
303
304</p><p><img src="TreeMapping.svg" alt="TreeMapping.svg" width="40%">
305
306</p><p>One interesting consequence of this mapping is that a
307breadth-first traversal of the tree is implemented as a simple
308linear scan of the array, which is in fact what the
309<tt>rcu_for_each_node_breadth_first()</tt> macro does.
310This macro is used at the beginning and ends of grace periods.
311
312</p><p>Each entry of the <tt>->level</tt> array references
313the first <tt>rcu_node</tt> structure on the corresponding level
314of the tree, for example, as shown below:
315
316</p><p><img src="TreeMappingLevel.svg" alt="TreeMappingLevel.svg" width="40%">
317
318</p><p>The zero<sup>th</sup> element of the array references the root
319<tt>rcu_node</tt> structure, the first element references the
320first child of the root <tt>rcu_node</tt>, and finally the second
321element references the first leaf <tt>rcu_node</tt> structure.
322
323</p><p>For whatever it is worth, if you draw the tree to be tree-shaped
324rather than array-shaped, it is easy to draw a planar representation:
325
326</p><p><img src="TreeLevel.svg" alt="TreeLevel.svg" width="60%">
327
328</p><p>Finally, the <tt>->rda</tt> field references a per-CPU
329pointer to the corresponding CPU's <tt>rcu_data</tt> structure.
330
331</p><p>All of these fields are constant once initialization is complete,
332and therefore need no protection.
333
334<h5>Grace-Period Tracking</h5>
335
336<p>This portion of the <tt>rcu_state</tt> structure is declared
337as follows:
338
339<pre>
340 1 unsigned long gp_seq;
341</pre>
342
343<p>RCU grace periods are numbered, and
344the <tt>->gp_seq</tt> field contains the current grace-period
345sequence number.
346The bottom two bits are the state of the current grace period,
347which can be zero for not yet started or one for in progress.
348In other words, if the bottom two bits of <tt>->gp_seq</tt> are
349zero, then RCU is idle.
350Any other value in the bottom two bits indicates that something is broken.
351This field is protected by the root <tt>rcu_node</tt> structure's
352<tt>->lock</tt> field.
353
354</p><p>There are <tt>->gp_seq</tt> fields
355in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
356as well.
357The fields in the <tt>rcu_state</tt> structure represent the
358most current value, and those of the other structures are compared
359in order to detect the beginnings and ends of grace periods in a distributed
360fashion.
361The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
362(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
363
364<h5>Miscellaneous</h5>
365
366<p>This portion of the <tt>rcu_state</tt> structure is declared
367as follows:
368
369<pre>
370 1 unsigned long gp_max;
371 2 char abbr;
372 3 char *name;
373</pre>
374
375<p>The <tt>->gp_max</tt> field tracks the duration of the longest
376grace period in jiffies.
377It is protected by the root <tt>rcu_node</tt>'s <tt>->lock</tt>.
378
379<p>The <tt>->name</tt> and <tt>->abbr</tt> fields distinguish
380between preemptible RCU (“rcu_preempt” and “p”)
381and non-preemptible RCU (“rcu_sched” and “s”).
382These fields are used for diagnostic and tracing purposes.
383
384<h3><a name="The rcu_node Structure">
385The <tt>rcu_node</tt> Structure</a></h3>
386
387<p>The <tt>rcu_node</tt> structures form the combining
388tree that propagates quiescent-state
389information from the leaves to the root and also that propagates
390grace-period information from the root down to the leaves.
391They provides local copies of the grace-period state in order
392to allow this information to be accessed in a synchronized
393manner without suffering the scalability limitations that
394would otherwise be imposed by global locking.
395In <tt>CONFIG_PREEMPT_RCU</tt> kernels, they manage the lists
396of tasks that have blocked while in their current
397RCU read-side critical section.
398In <tt>CONFIG_PREEMPT_RCU</tt> with
399<tt>CONFIG_RCU_BOOST</tt>, they manage the
400per-<tt>rcu_node</tt> priority-boosting
401kernel threads (kthreads) and state.
402Finally, they record CPU-hotplug state in order to determine
403which CPUs should be ignored during a given grace period.
404
405</p><p>The <tt>rcu_node</tt> structure's fields are discussed,
406singly and in groups, in the following sections.
407
408<h5>Connection to Combining Tree</h5>
409
410<p>This portion of the <tt>rcu_node</tt> structure is declared
411as follows:
412
413<pre>
414 1 struct rcu_node *parent;
415 2 u8 level;
416 3 u8 grpnum;
417 4 unsigned long grpmask;
418 5 int grplo;
419 6 int grphi;
420</pre>
421
422<p>The <tt>->parent</tt> pointer references the <tt>rcu_node</tt>
423one level up in the tree, and is <tt>NULL</tt> for the root
424<tt>rcu_node</tt>.
425The RCU implementation makes heavy use of this field to push quiescent
426states up the tree.
427The <tt>->level</tt> field gives the level in the tree, with
428the root being at level zero, its children at level one, and so on.
429The <tt>->grpnum</tt> field gives this node's position within
430the children of its parent, so this number can range between 0 and 31
431on 32-bit systems and between 0 and 63 on 64-bit systems.
432The <tt>->level</tt> and <tt>->grpnum</tt> fields are
433used only during initialization and for tracing.
434The <tt>->grpmask</tt> field is the bitmask counterpart of
435<tt>->grpnum</tt>, and therefore always has exactly one bit set.
436This mask is used to clear the bit corresponding to this <tt>rcu_node</tt>
437structure in its parent's bitmasks, which are described later.
438Finally, the <tt>->grplo</tt> and <tt>->grphi</tt> fields
439contain the lowest and highest numbered CPU served by this
440<tt>rcu_node</tt> structure, respectively.
441
442</p><p>All of these fields are constant, and thus do not require any
443synchronization.
444
445<h5>Synchronization</h5>
446
447<p>This field of the <tt>rcu_node</tt> structure is declared
448as follows:
449
450<pre>
451 1 raw_spinlock_t lock;
452</pre>
453
454<p>This field is used to protect the remaining fields in this structure,
455unless otherwise stated.
456That said, all of the fields in this structure can be accessed without
457locking for tracing purposes.
458Yes, this can result in confusing traces, but better some tracing confusion
459than to be heisenbugged out of existence.
460
461<h5>Grace-Period Tracking</h5>
462
463<p>This portion of the <tt>rcu_node</tt> structure is declared
464as follows:
465
466<pre>
467 1 unsigned long gp_seq;
468 2 unsigned long gp_seq_needed;
469</pre>
470
471<p>The <tt>rcu_node</tt> structures' <tt>->gp_seq</tt> fields are
472the counterparts of the field of the same name in the <tt>rcu_state</tt>
473structure.
474They each may lag up to one step behind their <tt>rcu_state</tt>
475counterpart.
476If the bottom two bits of a given <tt>rcu_node</tt> structure's
477<tt>->gp_seq</tt> field is zero, then this <tt>rcu_node</tt>
478structure believes that RCU is idle.
479</p><p>The <tt>>gp_seq</tt> field of each <tt>rcu_node</tt>
480structure is updated at the beginning and the end
481of each grace period.
482
483<p>The <tt>->gp_seq_needed</tt> fields record the
484furthest-in-the-future grace period request seen by the corresponding
485<tt>rcu_node</tt> structure. The request is considered fulfilled when
486the value of the <tt>->gp_seq</tt> field equals or exceeds that of
487the <tt>->gp_seq_needed</tt> field.
488
489<table>
490<tr><th> </th></tr>
491<tr><th align="left">Quick Quiz:</th></tr>
492<tr><td>
493 Suppose that this <tt>rcu_node</tt> structure doesn't see
494 a request for a very long time.
495 Won't wrapping of the <tt>->gp_seq</tt> field cause
496 problems?
497</td></tr>
498<tr><th align="left">Answer:</th></tr>
499<tr><td bgcolor="#ffffff"><font color="ffffff">
500 No, because if the <tt>->gp_seq_needed</tt> field lags behind the
501 <tt>->gp_seq</tt> field, the <tt>->gp_seq_needed</tt> field
502 will be updated at the end of the grace period.
503 Modulo-arithmetic comparisons therefore will always get the
504 correct answer, even with wrapping.
505</font></td></tr>
506<tr><td> </td></tr>
507</table>
508
509<h5>Quiescent-State Tracking</h5>
510
511<p>These fields manage the propagation of quiescent states up the
512combining tree.
513
514</p><p>This portion of the <tt>rcu_node</tt> structure has fields
515as follows:
516
517<pre>
518 1 unsigned long qsmask;
519 2 unsigned long expmask;
520 3 unsigned long qsmaskinit;
521 4 unsigned long expmaskinit;
522</pre>
523
524<p>The <tt>->qsmask</tt> field tracks which of this
525<tt>rcu_node</tt> structure's children still need to report
526quiescent states for the current normal grace period.
527Such children will have a value of 1 in their corresponding bit.
528Note that the leaf <tt>rcu_node</tt> structures should be
529thought of as having <tt>rcu_data</tt> structures as their
530children.
531Similarly, the <tt>->expmask</tt> field tracks which
532of this <tt>rcu_node</tt> structure's children still need to report
533quiescent states for the current expedited grace period.
534An expedited grace period has
535the same conceptual properties as a normal grace period, but the
536expedited implementation accepts extreme CPU overhead to obtain
537much lower grace-period latency, for example, consuming a few
538tens of microseconds worth of CPU time to reduce grace-period
539duration from milliseconds to tens of microseconds.
540The <tt>->qsmaskinit</tt> field tracks which of this
541<tt>rcu_node</tt> structure's children cover for at least
542one online CPU.
543This mask is used to initialize <tt>->qsmask</tt>,
544and <tt>->expmaskinit</tt> is used to initialize
545<tt>->expmask</tt> and the beginning of the
546normal and expedited grace periods, respectively.
547
548<table>
549<tr><th> </th></tr>
550<tr><th align="left">Quick Quiz:</th></tr>
551<tr><td>
552 Why are these bitmasks protected by locking?
553 Come on, haven't you heard of atomic instructions???
554</td></tr>
555<tr><th align="left">Answer:</th></tr>
556<tr><td bgcolor="#ffffff"><font color="ffffff">
557 Lockless grace-period computation! Such a tantalizing possibility!
558 </font>
559
560 <p><font color="ffffff">But consider the following sequence of events:
561 </font>
562
563 <ol>
564 <li> <font color="ffffff">CPU 0 has been in dyntick-idle
565 mode for quite some time.
566 When it wakes up, it notices that the current RCU
567 grace period needs it to report in, so it sets a
568 flag where the scheduling clock interrupt will find it.
569 </font><p>
570 <li> <font color="ffffff">Meanwhile, CPU 1 is running
571 <tt>force_quiescent_state()</tt>,
572 and notices that CPU 0 has been in dyntick idle mode,
573 which qualifies as an extended quiescent state.
574 </font><p>
575 <li> <font color="ffffff">CPU 0's scheduling clock
576 interrupt fires in the
577 middle of an RCU read-side critical section, and notices
578 that the RCU core needs something, so commences RCU softirq
579 processing.
580 </font>
581 <p>
582 <li> <font color="ffffff">CPU 0's softirq handler
583 executes and is just about ready
584 to report its quiescent state up the <tt>rcu_node</tt>
585 tree.
586 </font><p>
587 <li> <font color="ffffff">But CPU 1 beats it to the punch,
588 completing the current
589 grace period and starting a new one.
590 </font><p>
591 <li> <font color="ffffff">CPU 0 now reports its quiescent
592 state for the wrong
593 grace period.
594 That grace period might now end before the RCU read-side
595 critical section.
596 If that happens, disaster will ensue.
597 </font>
598 </ol>
599
600 <p><font color="ffffff">So the locking is absolutely required in
601 order to coordinate clearing of the bits with updating of the
602 grace-period sequence number in <tt>->gp_seq</tt>.
603</font></td></tr>
604<tr><td> </td></tr>
605</table>
606
607<h5>Blocked-Task Management</h5>
608
609<p><tt>PREEMPT_RCU</tt> allows tasks to be preempted in the
610midst of their RCU read-side critical sections, and these tasks
611must be tracked explicitly.
612The details of exactly why and how they are tracked will be covered
613in a separate article on RCU read-side processing.
614For now, it is enough to know that the <tt>rcu_node</tt>
615structure tracks them.
616
617<pre>
618 1 struct list_head blkd_tasks;
619 2 struct list_head *gp_tasks;
620 3 struct list_head *exp_tasks;
621 4 bool wait_blkd_tasks;
622</pre>
623
624<p>The <tt>->blkd_tasks</tt> field is a list header for
625the list of blocked and preempted tasks.
626As tasks undergo context switches within RCU read-side critical
627sections, their <tt>task_struct</tt> structures are enqueued
628(via the <tt>task_struct</tt>'s <tt>->rcu_node_entry</tt>
629field) onto the head of the <tt>->blkd_tasks</tt> list for the
630leaf <tt>rcu_node</tt> structure corresponding to the CPU
631on which the outgoing context switch executed.
632As these tasks later exit their RCU read-side critical sections,
633they remove themselves from the list.
634This list is therefore in reverse time order, so that if one of the tasks
635is blocking the current grace period, all subsequent tasks must
636also be blocking that same grace period.
637Therefore, a single pointer into this list suffices to track
638all tasks blocking a given grace period.
639That pointer is stored in <tt>->gp_tasks</tt> for normal
640grace periods and in <tt>->exp_tasks</tt> for expedited
641grace periods.
642These last two fields are <tt>NULL</tt> if either there is
643no grace period in flight or if there are no blocked tasks
644preventing that grace period from completing.
645If either of these two pointers is referencing a task that
646removes itself from the <tt>->blkd_tasks</tt> list,
647then that task must advance the pointer to the next task on
648the list, or set the pointer to <tt>NULL</tt> if there
649are no subsequent tasks on the list.
650
651</p><p>For example, suppose that tasks T1, T2, and T3 are
652all hard-affinitied to the largest-numbered CPU in the system.
653Then if task T1 blocked in an RCU read-side
654critical section, then an expedited grace period started,
655then task T2 blocked in an RCU read-side critical section,
656then a normal grace period started, and finally task 3 blocked
657in an RCU read-side critical section, then the state of the
658last leaf <tt>rcu_node</tt> structure's blocked-task list
659would be as shown below:
660
661</p><p><img src="blkd_task.svg" alt="blkd_task.svg" width="60%">
662
663</p><p>Task T1 is blocking both grace periods, task T2 is
664blocking only the normal grace period, and task T3 is blocking
665neither grace period.
666Note that these tasks will not remove themselves from this list
667immediately upon resuming execution.
668They will instead remain on the list until they execute the outermost
669<tt>rcu_read_unlock()</tt> that ends their RCU read-side critical
670section.
671
672<p>
673The <tt>->wait_blkd_tasks</tt> field indicates whether or not
674the current grace period is waiting on a blocked task.
675
676<h5>Sizing the <tt>rcu_node</tt> Array</h5>
677
678<p>The <tt>rcu_node</tt> array is sized via a series of
679C-preprocessor expressions as follows:
680
681<pre>
682 1 #ifdef CONFIG_RCU_FANOUT
683 2 #define RCU_FANOUT CONFIG_RCU_FANOUT
684 3 #else
685 4 # ifdef CONFIG_64BIT
686 5 # define RCU_FANOUT 64
687 6 # else
688 7 # define RCU_FANOUT 32
689 8 # endif
690 9 #endif
69110
69211 #ifdef CONFIG_RCU_FANOUT_LEAF
69312 #define RCU_FANOUT_LEAF CONFIG_RCU_FANOUT_LEAF
69413 #else
69514 # ifdef CONFIG_64BIT
69615 # define RCU_FANOUT_LEAF 64
69716 # else
69817 # define RCU_FANOUT_LEAF 32
69918 # endif
70019 #endif
70120
70221 #define RCU_FANOUT_1 (RCU_FANOUT_LEAF)
70322 #define RCU_FANOUT_2 (RCU_FANOUT_1 * RCU_FANOUT)
70423 #define RCU_FANOUT_3 (RCU_FANOUT_2 * RCU_FANOUT)
70524 #define RCU_FANOUT_4 (RCU_FANOUT_3 * RCU_FANOUT)
70625
70726 #if NR_CPUS <= RCU_FANOUT_1
70827 # define RCU_NUM_LVLS 1
70928 # define NUM_RCU_LVL_0 1
71029 # define NUM_RCU_NODES NUM_RCU_LVL_0
71130 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0 }
71231 # define RCU_NODE_NAME_INIT { "rcu_node_0" }
71332 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0" }
71433 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0" }
71534 #elif NR_CPUS <= RCU_FANOUT_2
71635 # define RCU_NUM_LVLS 2
71736 # define NUM_RCU_LVL_0 1
71837 # define NUM_RCU_LVL_1 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_1)
71938 # define NUM_RCU_NODES (NUM_RCU_LVL_0 + NUM_RCU_LVL_1)
72039 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0, NUM_RCU_LVL_1 }
72140 # define RCU_NODE_NAME_INIT { "rcu_node_0", "rcu_node_1" }
72241 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0", "rcu_node_fqs_1" }
72342 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0", "rcu_node_exp_1" }
72443 #elif NR_CPUS <= RCU_FANOUT_3
72544 # define RCU_NUM_LVLS 3
72645 # define NUM_RCU_LVL_0 1
72746 # define NUM_RCU_LVL_1 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_2)
72847 # define NUM_RCU_LVL_2 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_1)
72948 # define NUM_RCU_NODES (NUM_RCU_LVL_0 + NUM_RCU_LVL_1 + NUM_RCU_LVL_2)
73049 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0, NUM_RCU_LVL_1, NUM_RCU_LVL_2 }
73150 # define RCU_NODE_NAME_INIT { "rcu_node_0", "rcu_node_1", "rcu_node_2" }
73251 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0", "rcu_node_fqs_1", "rcu_node_fqs_2" }
73352 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0", "rcu_node_exp_1", "rcu_node_exp_2" }
73453 #elif NR_CPUS <= RCU_FANOUT_4
73554 # define RCU_NUM_LVLS 4
73655 # define NUM_RCU_LVL_0 1
73756 # define NUM_RCU_LVL_1 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_3)
73857 # define NUM_RCU_LVL_2 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_2)
73958 # define NUM_RCU_LVL_3 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_1)
74059 # define NUM_RCU_NODES (NUM_RCU_LVL_0 + NUM_RCU_LVL_1 + NUM_RCU_LVL_2 + NUM_RCU_LVL_3)
74160 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0, NUM_RCU_LVL_1, NUM_RCU_LVL_2, NUM_RCU_LVL_3 }
74261 # define RCU_NODE_NAME_INIT { "rcu_node_0", "rcu_node_1", "rcu_node_2", "rcu_node_3" }
74362 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0", "rcu_node_fqs_1", "rcu_node_fqs_2", "rcu_node_fqs_3" }
74463 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0", "rcu_node_exp_1", "rcu_node_exp_2", "rcu_node_exp_3" }
74564 #else
74665 # error "CONFIG_RCU_FANOUT insufficient for NR_CPUS"
74766 #endif
748</pre>
749
750<p>The maximum number of levels in the <tt>rcu_node</tt> structure
751is currently limited to four, as specified by lines 21-24
752and the structure of the subsequent “if” statement.
753For 32-bit systems, this allows 16*32*32*32=524,288 CPUs, which
754should be sufficient for the next few years at least.
755For 64-bit systems, 16*64*64*64=4,194,304 CPUs is allowed, which
756should see us through the next decade or so.
757This four-level tree also allows kernels built with
758<tt>CONFIG_RCU_FANOUT=8</tt> to support up to 4096 CPUs,
759which might be useful in very large systems having eight CPUs per
760socket (but please note that no one has yet shown any measurable
761performance degradation due to misaligned socket and <tt>rcu_node</tt>
762boundaries).
763In addition, building kernels with a full four levels of <tt>rcu_node</tt>
764tree permits better testing of RCU's combining-tree code.
765
766</p><p>The <tt>RCU_FANOUT</tt> symbol controls how many children
767are permitted at each non-leaf level of the <tt>rcu_node</tt> tree.
768If the <tt>CONFIG_RCU_FANOUT</tt> Kconfig option is not specified,
769it is set based on the word size of the system, which is also
770the Kconfig default.
771
772</p><p>The <tt>RCU_FANOUT_LEAF</tt> symbol controls how many CPUs are
773handled by each leaf <tt>rcu_node</tt> structure.
774Experience has shown that allowing a given leaf <tt>rcu_node</tt>
775structure to handle 64 CPUs, as permitted by the number of bits in
776the <tt>->qsmask</tt> field on a 64-bit system, results in
777excessive contention for the leaf <tt>rcu_node</tt> structures'
778<tt>->lock</tt> fields.
779The number of CPUs per leaf <tt>rcu_node</tt> structure is therefore
780limited to 16 given the default value of <tt>CONFIG_RCU_FANOUT_LEAF</tt>.
781If <tt>CONFIG_RCU_FANOUT_LEAF</tt> is unspecified, the value
782selected is based on the word size of the system, just as for
783<tt>CONFIG_RCU_FANOUT</tt>.
784Lines 11-19 perform this computation.
785
786</p><p>Lines 21-24 compute the maximum number of CPUs supported by
787a single-level (which contains a single <tt>rcu_node</tt> structure),
788two-level, three-level, and four-level <tt>rcu_node</tt> tree,
789respectively, given the fanout specified by <tt>RCU_FANOUT</tt>
790and <tt>RCU_FANOUT_LEAF</tt>.
791These numbers of CPUs are retained in the
792<tt>RCU_FANOUT_1</tt>,
793<tt>RCU_FANOUT_2</tt>,
794<tt>RCU_FANOUT_3</tt>, and
795<tt>RCU_FANOUT_4</tt>
796C-preprocessor variables, respectively.
797
798</p><p>These variables are used to control the C-preprocessor <tt>#if</tt>
799statement spanning lines 26-66 that computes the number of
800<tt>rcu_node</tt> structures required for each level of the tree,
801as well as the number of levels required.
802The number of levels is placed in the <tt>NUM_RCU_LVLS</tt>
803C-preprocessor variable by lines 27, 35, 44, and 54.
804The number of <tt>rcu_node</tt> structures for the topmost level
805of the tree is always exactly one, and this value is unconditionally
806placed into <tt>NUM_RCU_LVL_0</tt> by lines 28, 36, 45, and 55.
807The rest of the levels (if any) of the <tt>rcu_node</tt> tree
808are computed by dividing the maximum number of CPUs by the
809fanout supported by the number of levels from the current level down,
810rounding up. This computation is performed by lines 37,
81146-47, and 56-58.
812Lines 31-33, 40-42, 50-52, and 62-63 create initializers
813for lockdep lock-class names.
814Finally, lines 64-66 produce an error if the maximum number of
815CPUs is too large for the specified fanout.
816
817<h3><a name="The rcu_segcblist Structure">
818The <tt>rcu_segcblist</tt> Structure</a></h3>
819
820The <tt>rcu_segcblist</tt> structure maintains a segmented list of
821callbacks as follows:
822
823<pre>
824 1 #define RCU_DONE_TAIL 0
825 2 #define RCU_WAIT_TAIL 1
826 3 #define RCU_NEXT_READY_TAIL 2
827 4 #define RCU_NEXT_TAIL 3
828 5 #define RCU_CBLIST_NSEGS 4
829 6
830 7 struct rcu_segcblist {
831 8 struct rcu_head *head;
832 9 struct rcu_head **tails[RCU_CBLIST_NSEGS];
83310 unsigned long gp_seq[RCU_CBLIST_NSEGS];
83411 long len;
83512 long len_lazy;
83613 };
837</pre>
838
839<p>
840The segments are as follows:
841
842<ol>
843<li> <tt>RCU_DONE_TAIL</tt>: Callbacks whose grace periods have elapsed.
844 These callbacks are ready to be invoked.
845<li> <tt>RCU_WAIT_TAIL</tt>: Callbacks that are waiting for the
846 current grace period.
847 Note that different CPUs can have different ideas about which
848 grace period is current, hence the <tt>->gp_seq</tt> field.
849<li> <tt>RCU_NEXT_READY_TAIL</tt>: Callbacks waiting for the next
850 grace period to start.
851<li> <tt>RCU_NEXT_TAIL</tt>: Callbacks that have not yet been
852 associated with a grace period.
853</ol>
854
855<p>
856The <tt>->head</tt> pointer references the first callback or
857is <tt>NULL</tt> if the list contains no callbacks (which is
858<i>not</i> the same as being empty).
859Each element of the <tt>->tails[]</tt> array references the
860<tt>->next</tt> pointer of the last callback in the corresponding
861segment of the list, or the list's <tt>->head</tt> pointer if
862that segment and all previous segments are empty.
863If the corresponding segment is empty but some previous segment is
864not empty, then the array element is identical to its predecessor.
865Older callbacks are closer to the head of the list, and new callbacks
866are added at the tail.
867This relationship between the <tt>->head</tt> pointer, the
868<tt>->tails[]</tt> array, and the callbacks is shown in this
869diagram:
870
871</p><p><img src="nxtlist.svg" alt="nxtlist.svg" width="40%">
872
873</p><p>In this figure, the <tt>->head</tt> pointer references the
874first
875RCU callback in the list.
876The <tt>->tails[RCU_DONE_TAIL]</tt> array element references
877the <tt>->head</tt> pointer itself, indicating that none
878of the callbacks is ready to invoke.
879The <tt>->tails[RCU_WAIT_TAIL]</tt> array element references callback
880CB 2's <tt>->next</tt> pointer, which indicates that
881CB 1 and CB 2 are both waiting on the current grace period,
882give or take possible disagreements about exactly which grace period
883is the current one.
884The <tt>->tails[RCU_NEXT_READY_TAIL]</tt> array element
885references the same RCU callback that <tt>->tails[RCU_WAIT_TAIL]</tt>
886does, which indicates that there are no callbacks waiting on the next
887RCU grace period.
888The <tt>->tails[RCU_NEXT_TAIL]</tt> array element references
889CB 4's <tt>->next</tt> pointer, indicating that all the
890remaining RCU callbacks have not yet been assigned to an RCU grace
891period.
892Note that the <tt>->tails[RCU_NEXT_TAIL]</tt> array element
893always references the last RCU callback's <tt>->next</tt> pointer
894unless the callback list is empty, in which case it references
895the <tt>->head</tt> pointer.
896
897<p>
898There is one additional important special case for the
899<tt>->tails[RCU_NEXT_TAIL]</tt> array element: It can be <tt>NULL</tt>
900when this list is <i>disabled</i>.
901Lists are disabled when the corresponding CPU is offline or when
902the corresponding CPU's callbacks are offloaded to a kthread,
903both of which are described elsewhere.
904
905</p><p>CPUs advance their callbacks from the
906<tt>RCU_NEXT_TAIL</tt> to the <tt>RCU_NEXT_READY_TAIL</tt> to the
907<tt>RCU_WAIT_TAIL</tt> to the <tt>RCU_DONE_TAIL</tt> list segments
908as grace periods advance.
909
910</p><p>The <tt>->gp_seq[]</tt> array records grace-period
911numbers corresponding to the list segments.
912This is what allows different CPUs to have different ideas as to
913which is the current grace period while still avoiding premature
914invocation of their callbacks.
915In particular, this allows CPUs that go idle for extended periods
916to determine which of their callbacks are ready to be invoked after
917reawakening.
918
919</p><p>The <tt>->len</tt> counter contains the number of
920callbacks in <tt>->head</tt>, and the
921<tt>->len_lazy</tt> contains the number of those callbacks that
922are known to only free memory, and whose invocation can therefore
923be safely deferred.
924
925<p><b>Important note</b>: It is the <tt>->len</tt> field that
926determines whether or not there are callbacks associated with
927this <tt>rcu_segcblist</tt> structure, <i>not</i> the <tt>->head</tt>
928pointer.
929The reason for this is that all the ready-to-invoke callbacks
930(that is, those in the <tt>RCU_DONE_TAIL</tt> segment) are extracted
931all at once at callback-invocation time (<tt>rcu_do_batch</tt>), due
932to which <tt>->head</tt> may be set to NULL if there are no not-done
933callbacks remaining in the <tt>rcu_segcblist</tt>.
934If callback invocation must be postponed, for example, because a
935high-priority process just woke up on this CPU, then the remaining
936callbacks are placed back on the <tt>RCU_DONE_TAIL</tt> segment and
937<tt>->head</tt> once again points to the start of the segment.
938In short, the head field can briefly be <tt>NULL</tt> even though the
939CPU has callbacks present the entire time.
940Therefore, it is not appropriate to test the <tt>->head</tt> pointer
941for <tt>NULL</tt>.
942
943<p>In contrast, the <tt>->len</tt> and <tt>->len_lazy</tt> counts
944are adjusted only after the corresponding callbacks have been invoked.
945This means that the <tt>->len</tt> count is zero only if
946the <tt>rcu_segcblist</tt> structure really is devoid of callbacks.
947Of course, off-CPU sampling of the <tt>->len</tt> count requires
948careful use of appropriate synchronization, for example, memory barriers.
949This synchronization can be a bit subtle, particularly in the case
950of <tt>rcu_barrier()</tt>.
951
952<h3><a name="The rcu_data Structure">
953The <tt>rcu_data</tt> Structure</a></h3>
954
955<p>The <tt>rcu_data</tt> maintains the per-CPU state for the RCU subsystem.
956The fields in this structure may be accessed only from the corresponding
957CPU (and from tracing) unless otherwise stated.
958This structure is the
959focus of quiescent-state detection and RCU callback queuing.
960It also tracks its relationship to the corresponding leaf
961<tt>rcu_node</tt> structure to allow more-efficient
962propagation of quiescent states up the <tt>rcu_node</tt>
963combining tree.
964Like the <tt>rcu_node</tt> structure, it provides a local
965copy of the grace-period information to allow for-free
966synchronized
967access to this information from the corresponding CPU.
968Finally, this structure records past dyntick-idle state
969for the corresponding CPU and also tracks statistics.
970
971</p><p>The <tt>rcu_data</tt> structure's fields are discussed,
972singly and in groups, in the following sections.
973
974<h5>Connection to Other Data Structures</h5>
975
976<p>This portion of the <tt>rcu_data</tt> structure is declared
977as follows:
978
979<pre>
980 1 int cpu;
981 2 struct rcu_node *mynode;
982 3 unsigned long grpmask;
983 4 bool beenonline;
984</pre>
985
986<p>The <tt>->cpu</tt> field contains the number of the
987corresponding CPU and the <tt>->mynode</tt> field references the
988corresponding <tt>rcu_node</tt> structure.
989The <tt>->mynode</tt> is used to propagate quiescent states
990up the combining tree.
991These two fields are constant and therefore do not require synchronization.
992
993<p>The <tt>->grpmask</tt> field indicates the bit in
994the <tt>->mynode->qsmask</tt> corresponding to this
995<tt>rcu_data</tt> structure, and is also used when propagating
996quiescent states.
997The <tt>->beenonline</tt> flag is set whenever the corresponding
998CPU comes online, which means that the debugfs tracing need not dump
999out any <tt>rcu_data</tt> structure for which this flag is not set.
1000
1001<h5>Quiescent-State and Grace-Period Tracking</h5>
1002
1003<p>This portion of the <tt>rcu_data</tt> structure is declared
1004as follows:
1005
1006<pre>
1007 1 unsigned long gp_seq;
1008 2 unsigned long gp_seq_needed;
1009 3 bool cpu_no_qs;
1010 4 bool core_needs_qs;
1011 5 bool gpwrap;
1012</pre>
1013
1014<p>The <tt>->gp_seq</tt> field is the counterpart of the field of the same
1015name in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures. The
1016<tt>->gp_seq_needed</tt> field is the counterpart of the field of the same
1017name in the rcu_node</tt> structure.
1018They may each lag up to one behind their <tt>rcu_node</tt>
1019counterparts, but in <tt>CONFIG_NO_HZ_IDLE</tt> and
1020<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
1021arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
1022will catch up upon exit from dyntick-idle mode).
1023If the lower two bits of a given <tt>rcu_data</tt> structure's
1024<tt>->gp_seq</tt> are zero, then this <tt>rcu_data</tt>
1025structure believes that RCU is idle.
1026
1027<table>
1028<tr><th> </th></tr>
1029<tr><th align="left">Quick Quiz:</th></tr>
1030<tr><td>
1031 All this replication of the grace period numbers can only cause
1032 massive confusion.
1033 Why not just keep a global sequence number and be done with it???
1034</td></tr>
1035<tr><th align="left">Answer:</th></tr>
1036<tr><td bgcolor="#ffffff"><font color="ffffff">
1037 Because if there was only a single global sequence
1038 numbers, there would need to be a single global lock to allow
1039 safely accessing and updating it.
1040 And if we are not going to have a single global lock, we need
1041 to carefully manage the numbers on a per-node basis.
1042 Recall from the answer to a previous Quick Quiz that the consequences
1043 of applying a previously sampled quiescent state to the wrong
1044 grace period are quite severe.
1045</font></td></tr>
1046<tr><td> </td></tr>
1047</table>
1048
1049<p>The <tt>->cpu_no_qs</tt> flag indicates that the
1050CPU has not yet passed through a quiescent state,
1051while the <tt>->core_needs_qs</tt> flag indicates that the
1052RCU core needs a quiescent state from the corresponding CPU.
1053The <tt>->gpwrap</tt> field indicates that the corresponding
1054CPU has remained idle for so long that the
1055<tt>gp_seq</tt> counter is in danger of overflow, which
1056will cause the CPU to disregard the values of its counters on
1057its next exit from idle.
1058
1059<h5>RCU Callback Handling</h5>
1060
1061<p>In the absence of CPU-hotplug events, RCU callbacks are invoked by
1062the same CPU that registered them.
1063This is strictly a cache-locality optimization: callbacks can and
1064do get invoked on CPUs other than the one that registered them.
1065After all, if the CPU that registered a given callback has gone
1066offline before the callback can be invoked, there really is no other
1067choice.
1068
1069</p><p>This portion of the <tt>rcu_data</tt> structure is declared
1070as follows:
1071
1072<pre>
1073 1 struct rcu_segcblist cblist;
1074 2 long qlen_last_fqs_check;
1075 3 unsigned long n_cbs_invoked;
1076 4 unsigned long n_nocbs_invoked;
1077 5 unsigned long n_cbs_orphaned;
1078 6 unsigned long n_cbs_adopted;
1079 7 unsigned long n_force_qs_snap;
1080 8 long blimit;
1081</pre>
1082
1083<p>The <tt>->cblist</tt> structure is the segmented callback list
1084described earlier.
1085The CPU advances the callbacks in its <tt>rcu_data</tt> structure
1086whenever it notices that another RCU grace period has completed.
1087The CPU detects the completion of an RCU grace period by noticing
1088that the value of its <tt>rcu_data</tt> structure's
1089<tt>->gp_seq</tt> field differs from that of its leaf
1090<tt>rcu_node</tt> structure.
1091Recall that each <tt>rcu_node</tt> structure's
1092<tt>->gp_seq</tt> field is updated at the beginnings and ends of each
1093grace period.
1094
1095<p>
1096The <tt>->qlen_last_fqs_check</tt> and
1097<tt>->n_force_qs_snap</tt> coordinate the forcing of quiescent
1098states from <tt>call_rcu()</tt> and friends when callback
1099lists grow excessively long.
1100
1101</p><p>The <tt>->n_cbs_invoked</tt>,
1102<tt>->n_cbs_orphaned</tt>, and <tt>->n_cbs_adopted</tt>
1103fields count the number of callbacks invoked,
1104sent to other CPUs when this CPU goes offline,
1105and received from other CPUs when those other CPUs go offline.
1106The <tt>->n_nocbs_invoked</tt> is used when the CPU's callbacks
1107are offloaded to a kthread.
1108
1109<p>
1110Finally, the <tt>->blimit</tt> counter is the maximum number of
1111RCU callbacks that may be invoked at a given time.
1112
1113<h5>Dyntick-Idle Handling</h5>
1114
1115<p>This portion of the <tt>rcu_data</tt> structure is declared
1116as follows:
1117
1118<pre>
1119 1 int dynticks_snap;
1120 2 unsigned long dynticks_fqs;
1121</pre>
1122
1123The <tt>->dynticks_snap</tt> field is used to take a snapshot
1124of the corresponding CPU's dyntick-idle state when forcing
1125quiescent states, and is therefore accessed from other CPUs.
1126Finally, the <tt>->dynticks_fqs</tt> field is used to
1127count the number of times this CPU is determined to be in
1128dyntick-idle state, and is used for tracing and debugging purposes.
1129
1130<p>
1131This portion of the rcu_data structure is declared as follows:
1132
1133<pre>
1134 1 long dynticks_nesting;
1135 2 long dynticks_nmi_nesting;
1136 3 atomic_t dynticks;
1137 4 bool rcu_need_heavy_qs;
1138 5 bool rcu_urgent_qs;
1139</pre>
1140
1141<p>These fields in the rcu_data structure maintain the per-CPU dyntick-idle
1142state for the corresponding CPU.
1143The fields may be accessed only from the corresponding CPU (and from tracing)
1144unless otherwise stated.
1145
1146<p>The <tt>->dynticks_nesting</tt> field counts the
1147nesting depth of process execution, so that in normal circumstances
1148this counter has value zero or one.
1149NMIs, irqs, and tracers are counted by the <tt>->dynticks_nmi_nesting</tt>
1150field.
1151Because NMIs cannot be masked, changes to this variable have to be
1152undertaken carefully using an algorithm provided by Andy Lutomirski.
1153The initial transition from idle adds one, and nested transitions
1154add two, so that a nesting level of five is represented by a
1155<tt>->dynticks_nmi_nesting</tt> value of nine.
1156This counter can therefore be thought of as counting the number
1157of reasons why this CPU cannot be permitted to enter dyntick-idle
1158mode, aside from process-level transitions.
1159
1160<p>However, it turns out that when running in non-idle kernel context,
1161the Linux kernel is fully capable of entering interrupt handlers that
1162never exit and perhaps also vice versa.
1163Therefore, whenever the <tt>->dynticks_nesting</tt> field is
1164incremented up from zero, the <tt>->dynticks_nmi_nesting</tt> field
1165is set to a large positive number, and whenever the
1166<tt>->dynticks_nesting</tt> field is decremented down to zero,
1167the the <tt>->dynticks_nmi_nesting</tt> field is set to zero.
1168Assuming that the number of misnested interrupts is not sufficient
1169to overflow the counter, this approach corrects the
1170<tt>->dynticks_nmi_nesting</tt> field every time the corresponding
1171CPU enters the idle loop from process context.
1172
1173</p><p>The <tt>->dynticks</tt> field counts the corresponding
1174CPU's transitions to and from either dyntick-idle or user mode, so
1175that this counter has an even value when the CPU is in dyntick-idle
1176mode or user mode and an odd value otherwise. The transitions to/from
1177user mode need to be counted for user mode adaptive-ticks support
1178(see timers/NO_HZ.txt).
1179
1180</p><p>The <tt>->rcu_need_heavy_qs</tt> field is used
1181to record the fact that the RCU core code would really like to
1182see a quiescent state from the corresponding CPU, so much so that
1183it is willing to call for heavy-weight dyntick-counter operations.
1184This flag is checked by RCU's context-switch and <tt>cond_resched()</tt>
1185code, which provide a momentary idle sojourn in response.
1186
1187</p><p>Finally, the <tt>->rcu_urgent_qs</tt> field is used to record
1188the fact that the RCU core code would really like to see a quiescent state from
1189the corresponding CPU, with the various other fields indicating just how badly
1190RCU wants this quiescent state.
1191This flag is checked by RCU's context-switch path
1192(<tt>rcu_note_context_switch</tt>) and the cond_resched code.
1193
1194<table>
1195<tr><th> </th></tr>
1196<tr><th align="left">Quick Quiz:</th></tr>
1197<tr><td>
1198 Why not simply combine the <tt>->dynticks_nesting</tt>
1199 and <tt>->dynticks_nmi_nesting</tt> counters into a
1200 single counter that just counts the number of reasons that
1201 the corresponding CPU is non-idle?
1202</td></tr>
1203<tr><th align="left">Answer:</th></tr>
1204<tr><td bgcolor="#ffffff"><font color="ffffff">
1205 Because this would fail in the presence of interrupts whose
1206 handlers never return and of handlers that manage to return
1207 from a made-up interrupt.
1208</font></td></tr>
1209<tr><td> </td></tr>
1210</table>
1211
1212<p>Additional fields are present for some special-purpose
1213builds, and are discussed separately.
1214
1215<h3><a name="The rcu_head Structure">
1216The <tt>rcu_head</tt> Structure</a></h3>
1217
1218<p>Each <tt>rcu_head</tt> structure represents an RCU callback.
1219These structures are normally embedded within RCU-protected data
1220structures whose algorithms use asynchronous grace periods.
1221In contrast, when using algorithms that block waiting for RCU grace periods,
1222RCU users need not provide <tt>rcu_head</tt> structures.
1223
1224</p><p>The <tt>rcu_head</tt> structure has fields as follows:
1225
1226<pre>
1227 1 struct rcu_head *next;
1228 2 void (*func)(struct rcu_head *head);
1229</pre>
1230
1231<p>The <tt>->next</tt> field is used
1232to link the <tt>rcu_head</tt> structures together in the
1233lists within the <tt>rcu_data</tt> structures.
1234The <tt>->func</tt> field is a pointer to the function
1235to be called when the callback is ready to be invoked, and
1236this function is passed a pointer to the <tt>rcu_head</tt>
1237structure.
1238However, <tt>kfree_rcu()</tt> uses the <tt>->func</tt>
1239field to record the offset of the <tt>rcu_head</tt>
1240structure within the enclosing RCU-protected data structure.
1241
1242</p><p>Both of these fields are used internally by RCU.
1243From the viewpoint of RCU users, this structure is an
1244opaque “cookie”.
1245
1246<table>
1247<tr><th> </th></tr>
1248<tr><th align="left">Quick Quiz:</th></tr>
1249<tr><td>
1250 Given that the callback function <tt>->func</tt>
1251 is passed a pointer to the <tt>rcu_head</tt> structure,
1252 how is that function supposed to find the beginning of the
1253 enclosing RCU-protected data structure?
1254</td></tr>
1255<tr><th align="left">Answer:</th></tr>
1256<tr><td bgcolor="#ffffff"><font color="ffffff">
1257 In actual practice, there is a separate callback function per
1258 type of RCU-protected data structure.
1259 The callback function can therefore use the <tt>container_of()</tt>
1260 macro in the Linux kernel (or other pointer-manipulation facilities
1261 in other software environments) to find the beginning of the
1262 enclosing structure.
1263</font></td></tr>
1264<tr><td> </td></tr>
1265</table>
1266
1267<h3><a name="RCU-Specific Fields in the task_struct Structure">
1268RCU-Specific Fields in the <tt>task_struct</tt> Structure</a></h3>
1269
1270<p>The <tt>CONFIG_PREEMPT_RCU</tt> implementation uses some
1271additional fields in the <tt>task_struct</tt> structure:
1272
1273<pre>
1274 1 #ifdef CONFIG_PREEMPT_RCU
1275 2 int rcu_read_lock_nesting;
1276 3 union rcu_special rcu_read_unlock_special;
1277 4 struct list_head rcu_node_entry;
1278 5 struct rcu_node *rcu_blocked_node;
1279 6 #endif /* #ifdef CONFIG_PREEMPT_RCU */
1280 7 #ifdef CONFIG_TASKS_RCU
1281 8 unsigned long rcu_tasks_nvcsw;
1282 9 bool rcu_tasks_holdout;
128310 struct list_head rcu_tasks_holdout_list;
128411 int rcu_tasks_idle_cpu;
128512 #endif /* #ifdef CONFIG_TASKS_RCU */
1286</pre>
1287
1288<p>The <tt>->rcu_read_lock_nesting</tt> field records the
1289nesting level for RCU read-side critical sections, and
1290the <tt>->rcu_read_unlock_special</tt> field is a bitmask
1291that records special conditions that require <tt>rcu_read_unlock()</tt>
1292to do additional work.
1293The <tt>->rcu_node_entry</tt> field is used to form lists of
1294tasks that have blocked within preemptible-RCU read-side critical
1295sections and the <tt>->rcu_blocked_node</tt> field references
1296the <tt>rcu_node</tt> structure whose list this task is a member of,
1297or <tt>NULL</tt> if it is not blocked within a preemptible-RCU
1298read-side critical section.
1299
1300<p>The <tt>->rcu_tasks_nvcsw</tt> field tracks the number of
1301voluntary context switches that this task had undergone at the
1302beginning of the current tasks-RCU grace period,
1303<tt>->rcu_tasks_holdout</tt> is set if the current tasks-RCU
1304grace period is waiting on this task, <tt>->rcu_tasks_holdout_list</tt>
1305is a list element enqueuing this task on the holdout list,
1306and <tt>->rcu_tasks_idle_cpu</tt> tracks which CPU this
1307idle task is running, but only if the task is currently running,
1308that is, if the CPU is currently idle.
1309
1310<h3><a name="Accessor Functions">
1311Accessor Functions</a></h3>
1312
1313<p>The following listing shows the
1314<tt>rcu_get_root()</tt>, <tt>rcu_for_each_node_breadth_first</tt> and
1315<tt>rcu_for_each_leaf_node()</tt> function and macros:
1316
1317<pre>
1318 1 static struct rcu_node *rcu_get_root(struct rcu_state *rsp)
1319 2 {
1320 3 return &rsp->node[0];
1321 4 }
1322 5
1323 6 #define rcu_for_each_node_breadth_first(rsp, rnp) \
1324 7 for ((rnp) = &(rsp)->node[0]; \
1325 8 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++)
1326 9
1327 10 #define rcu_for_each_leaf_node(rsp, rnp) \
1328 11 for ((rnp) = (rsp)->level[NUM_RCU_LVLS - 1]; \
1329 12 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++)
1330</pre>
1331
1332<p>The <tt>rcu_get_root()</tt> simply returns a pointer to the
1333first element of the specified <tt>rcu_state</tt> structure's
1334<tt>->node[]</tt> array, which is the root <tt>rcu_node</tt>
1335structure.
1336
1337</p><p>As noted earlier, the <tt>rcu_for_each_node_breadth_first()</tt>
1338macro takes advantage of the layout of the <tt>rcu_node</tt>
1339structures in the <tt>rcu_state</tt> structure's
1340<tt>->node[]</tt> array, performing a breadth-first traversal by
1341simply traversing the array in order.
1342Similarly, the <tt>rcu_for_each_leaf_node()</tt> macro traverses only
1343the last part of the array, thus traversing only the leaf
1344<tt>rcu_node</tt> structures.
1345
1346<table>
1347<tr><th> </th></tr>
1348<tr><th align="left">Quick Quiz:</th></tr>
1349<tr><td>
1350 What does
1351 <tt>rcu_for_each_leaf_node()</tt> do if the <tt>rcu_node</tt> tree
1352 contains only a single node?
1353</td></tr>
1354<tr><th align="left">Answer:</th></tr>
1355<tr><td bgcolor="#ffffff"><font color="ffffff">
1356 In the single-node case,
1357 <tt>rcu_for_each_leaf_node()</tt> traverses the single node.
1358</font></td></tr>
1359<tr><td> </td></tr>
1360</table>
1361
1362<h3><a name="Summary">
1363Summary</a></h3>
1364
1365So the state of RCU is represented by an <tt>rcu_state</tt> structure,
1366which contains a combining tree of <tt>rcu_node</tt> and
1367<tt>rcu_data</tt> structures.
1368Finally, in <tt>CONFIG_NO_HZ_IDLE</tt> kernels, each CPU's dyntick-idle
1369state is tracked by dynticks-related fields in the <tt>rcu_data</tt> structure.
1370
1371If you made it this far, you are well prepared to read the code
1372walkthroughs in the other articles in this series.
1373
1374<h3><a name="Acknowledgments">
1375Acknowledgments</a></h3>
1376
1377I owe thanks to Cyrill Gorcunov, Mathieu Desnoyers, Dhaval Giani, Paul
1378Turner, Abhishek Srivastava, Matt Kowalczyk, and Serge Hallyn
1379for helping me get this document into a more human-readable state.
1380
1381<h3><a name="Legal Statement">
1382Legal Statement</a></h3>
1383
1384<p>This work represents the view of the author and does not necessarily
1385represent the view of IBM.
1386
1387</p><p>Linux is a registered trademark of Linus Torvalds.
1388
1389</p><p>Other company, product, and service names may be trademarks or
1390service marks of others.
1391
1392</body></html>