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_data Structure">
23 The <tt>rcu_data</tt> Structure</a>
24<li> <a href="#The rcu_dynticks Structure">
25 The <tt>rcu_dynticks</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 <tt>CONFIG_RCU_FANOUT</tt> to be
129as small as 2 if you wish, which would permit only 16 CPUs, which
130is useful for testing.
131
132</p><p>This multi-level combining tree allows us to get most of the
133performance and scalability
134benefits of partitioning, even though RCU grace-period detection is
135inherently a global operation.
136The trick here is that only the last CPU to report a quiescent state
137into a given <tt>rcu_node</tt> structure need advance to the <tt>rcu_node</tt>
138structure at the next level up the tree.
139This means that at the leaf-level <tt>rcu_node</tt> structure, only
140one access out of sixteen will progress up the tree.
141For the internal <tt>rcu_node</tt> structures, the situation is even
142more extreme: Only one access out of sixty-four will progress up
143the tree.
144Because the vast majority of the CPUs do not progress up the tree,
145the lock contention remains roughly constant up the tree.
146No matter how many CPUs there are in the system, at most 64 quiescent-state
147reports per grace period will progress all the way to the root
148<tt>rcu_node</tt> structure, thus ensuring that the lock contention
149on that root <tt>rcu_node</tt> structure remains acceptably low.
150
151</p><p>In effect, the combining tree acts like a big shock absorber,
152keeping lock contention under control at all tree levels regardless
153of the level of loading on the system.
154
155</p><p>The Linux kernel actually supports multiple flavors of RCU
156running concurrently, so RCU builds separate data structures for each
157flavor.
158For example, for <tt>CONFIG_TREE_RCU=y</tt> kernels, RCU provides
159rcu_sched and rcu_bh, as shown below:
160
161</p><p><img src="BigTreeClassicRCUBH.svg" alt="BigTreeClassicRCUBH.svg" width="33%">
162
163</p><p>Energy efficiency is increasingly important, and for that
164reason the Linux kernel provides <tt>CONFIG_NO_HZ_IDLE</tt>, which
165turns off the scheduling-clock interrupts on idle CPUs, which in
166turn allows those CPUs to attain deeper sleep states and to consume
167less energy.
168CPUs whose scheduling-clock interrupts have been turned off are
169said to be in <i>dyntick-idle mode</i>.
170RCU must handle dyntick-idle CPUs specially
171because RCU would otherwise wake up each CPU on every grace period,
172which would defeat the whole purpose of <tt>CONFIG_NO_HZ_IDLE</tt>.
173RCU uses the <tt>rcu_dynticks</tt> structure to track
174which CPUs are in dyntick idle mode, as shown below:
175
176</p><p><img src="BigTreeClassicRCUBHdyntick.svg" alt="BigTreeClassicRCUBHdyntick.svg" width="33%">
177
178</p><p>However, if a CPU is in dyntick-idle mode, it is in that mode
179for all flavors of RCU.
180Therefore, a single <tt>rcu_dynticks</tt> structure is allocated per
181CPU, and all of a given CPU's <tt>rcu_data</tt> structures share
182that <tt>rcu_dynticks</tt>, as shown in the figure.
183
184</p><p>Kernels built with <tt>CONFIG_PREEMPT_RCU</tt> support
185rcu_preempt in addition to rcu_sched and rcu_bh, as shown below:
186
187</p><p><img src="BigTreePreemptRCUBHdyntick.svg" alt="BigTreePreemptRCUBHdyntick.svg" width="35%">
188
189</p><p>RCU updaters wait for normal grace periods by registering
190RCU callbacks, either directly via <tt>call_rcu()</tt> and
191friends (namely <tt>call_rcu_bh()</tt> and <tt>call_rcu_sched()</tt>),
192there being a separate interface per flavor of RCU)
193or indirectly via <tt>synchronize_rcu()</tt> and friends.
194RCU callbacks are represented by <tt>rcu_head</tt> structures,
195which are queued on <tt>rcu_data</tt> structures while they are
196waiting for a grace period to elapse, as shown in the following figure:
197
198</p><p><img src="BigTreePreemptRCUBHdyntickCB.svg" alt="BigTreePreemptRCUBHdyntickCB.svg" width="40%">
199
200</p><p>This figure shows how <tt>TREE_RCU</tt>'s and
201<tt>PREEMPT_RCU</tt>'s major data structures are related.
202Lesser data structures will be introduced with the algorithms that
203make use of them.
204
205</p><p>Note that each of the data structures in the above figure has
206its own synchronization:
207
208<p><ol>
209<li> Each <tt>rcu_state</tt> structures has a lock and a mutex,
210 and some fields are protected by the corresponding root
211 <tt>rcu_node</tt> structure's lock.
212<li> Each <tt>rcu_node</tt> structure has a spinlock.
213<li> The fields in <tt>rcu_data</tt> are private to the corresponding
214 CPU, although a few can be read and written by other CPUs.
215<li> Similarly, the fields in <tt>rcu_dynticks</tt> are private
216 to the corresponding CPU, although a few can be read by
217 other CPUs.
218</ol>
219
220<p>It is important to note that different data structures can have
221very different ideas about the state of RCU at any given time.
222For but one example, awareness of the start or end of a given RCU
223grace period propagates slowly through the data structures.
224This slow propagation is absolutely necessary for RCU to have good
225read-side performance.
226If this balkanized implementation seems foreign to you, one useful
227trick is to consider each instance of these data structures to be
228a different person, each having the usual slightly different
229view of reality.
230
231</p><p>The general role of each of these data structures is as
232follows:
233
234</p><ol>
235<li> <tt>rcu_state</tt>:
236 This structure forms the interconnection between the
237 <tt>rcu_node</tt> and <tt>rcu_data</tt> structures,
238 tracks grace periods, serves as short-term repository
239 for callbacks orphaned by CPU-hotplug events,
240 maintains <tt>rcu_barrier()</tt> state,
241 tracks expedited grace-period state,
242 and maintains state used to force quiescent states when
243 grace periods extend too long,
244<li> <tt>rcu_node</tt>: This structure forms the combining
245 tree that propagates quiescent-state
246 information from the leaves to the root, and also propagates
247 grace-period information from the root to the leaves.
248 It provides local copies of the grace-period state in order
249 to allow this information to be accessed in a synchronized
250 manner without suffering the scalability limitations that
251 would otherwise be imposed by global locking.
252 In <tt>CONFIG_PREEMPT_RCU</tt> kernels, it manages the lists
253 of tasks that have blocked while in their current
254 RCU read-side critical section.
255 In <tt>CONFIG_PREEMPT_RCU</tt> with
256 <tt>CONFIG_RCU_BOOST</tt>, it manages the
257 per-<tt>rcu_node</tt> priority-boosting
258 kernel threads (kthreads) and state.
259 Finally, it records CPU-hotplug state in order to determine
260 which CPUs should be ignored during a given grace period.
261<li> <tt>rcu_data</tt>: This per-CPU structure is the
262 focus of quiescent-state detection and RCU callback queuing.
263 It also tracks its relationship to the corresponding leaf
264 <tt>rcu_node</tt> structure to allow more-efficient
265 propagation of quiescent states up the <tt>rcu_node</tt>
266 combining tree.
267 Like the <tt>rcu_node</tt> structure, it provides a local
268 copy of the grace-period information to allow for-free
269 synchronized
270 access to this information from the corresponding CPU.
271 Finally, this structure records past dyntick-idle state
272 for the corresponding CPU and also tracks statistics.
273<li> <tt>rcu_dynticks</tt>:
274 This per-CPU structure tracks the current dyntick-idle
275 state for the corresponding CPU.
276 Unlike the other three structures, the <tt>rcu_dynticks</tt>
277 structure is not replicated per RCU flavor.
278<li> <tt>rcu_head</tt>:
279 This structure represents RCU callbacks, and is the
280 only structure allocated and managed by RCU users.
281 The <tt>rcu_head</tt> structure is normally embedded
282 within the RCU-protected data structure.
283</ol>
284
285<p>If all you wanted from this article was a general notion of how
286RCU's data structures are related, you are done.
287Otherwise, each of the following sections give more details on
288the <tt>rcu_state</tt>, <tt>rcu_node</tt>, <tt>rcu_data</tt>,
289and <tt>rcu_dynticks</tt> data structures.
290
291<h3><a name="The rcu_state Structure">
292The <tt>rcu_state</tt> Structure</a></h3>
293
294<p>The <tt>rcu_state</tt> structure is the base structure that
295represents a flavor of RCU.
296This structure forms the interconnection between the
297<tt>rcu_node</tt> and <tt>rcu_data</tt> structures,
298tracks grace periods, contains the lock used to
299synchronize with CPU-hotplug events,
300and maintains state used to force quiescent states when
301grace periods extend too long,
302
303</p><p>A few of the <tt>rcu_state</tt> structure's fields are discussed,
304singly and in groups, in the following sections.
305The more specialized fields are covered in the discussion of their
306use.
307
308<h5>Relationship to rcu_node and rcu_data Structures</h5>
309
310This portion of the <tt>rcu_state</tt> structure is declared
311as follows:
312
313<pre>
314 1 struct rcu_node node[NUM_RCU_NODES];
315 2 struct rcu_node *level[NUM_RCU_LVLS + 1];
316 3 struct rcu_data __percpu *rda;
317</pre>
318
319<table>
320<tr><th> </th></tr>
321<tr><th align="left">Quick Quiz:</th></tr>
322<tr><td>
323 Wait a minute!
324 You said that the <tt>rcu_node</tt> structures formed a tree,
325 but they are declared as a flat array!
326 What gives?
327</td></tr>
328<tr><th align="left">Answer:</th></tr>
329<tr><td bgcolor="#ffffff"><font color="ffffff">
330 The tree is laid out in the array.
331 The first node In the array is the head, the next set of nodes in the
332 array are children of the head node, and so on until the last set of
333 nodes in the array are the leaves.
334 </font>
335
336 <p><font color="ffffff">See the following diagrams to see how
337 this works.
338</font></td></tr>
339<tr><td> </td></tr>
340</table>
341
342<p>The <tt>rcu_node</tt> tree is embedded into the
343<tt>->node[]</tt> array as shown in the following figure:
344
345</p><p><img src="TreeMapping.svg" alt="TreeMapping.svg" width="40%">
346
347</p><p>One interesting consequence of this mapping is that a
348breadth-first traversal of the tree is implemented as a simple
349linear scan of the array, which is in fact what the
350<tt>rcu_for_each_node_breadth_first()</tt> macro does.
351This macro is used at the beginning and ends of grace periods.
352
353</p><p>Each entry of the <tt>->level</tt> array references
354the first <tt>rcu_node</tt> structure on the corresponding level
355of the tree, for example, as shown below:
356
357</p><p><img src="TreeMappingLevel.svg" alt="TreeMappingLevel.svg" width="40%">
358
359</p><p>The zero<sup>th</sup> element of the array references the root
360<tt>rcu_node</tt> structure, the first element references the
361first child of the root <tt>rcu_node</tt>, and finally the second
362element references the first leaf <tt>rcu_node</tt> structure.
363
364</p><p>For whatever it is worth, if you draw the tree to be tree-shaped
365rather than array-shaped, it is easy to draw a planar representation:
366
367</p><p><img src="TreeLevel.svg" alt="TreeLevel.svg" width="60%">
368
369</p><p>Finally, the <tt>->rda</tt> field references a per-CPU
370pointer to the corresponding CPU's <tt>rcu_data</tt> structure.
371
372</p><p>All of these fields are constant once initialization is complete,
373and therefore need no protection.
374
375<h5>Grace-Period Tracking</h5>
376
377<p>This portion of the <tt>rcu_state</tt> structure is declared
378as follows:
379
380<pre>
381 1 unsigned long gpnum;
382 2 unsigned long completed;
383</pre>
384
385<p>RCU grace periods are numbered, and
386the <tt>->gpnum</tt> field contains the number of the grace
387period that started most recently.
388The <tt>->completed</tt> field contains the number of the
389grace period that completed most recently.
390If the two fields are equal, the RCU grace period that most recently
391started has already completed, and therefore the corresponding
392flavor of RCU is idle.
393If <tt>->gpnum</tt> is one greater than <tt>->completed</tt>,
394then <tt>->gpnum</tt> gives the number of the current RCU
395grace period, which has not yet completed.
396Any other combination of values indicates that something is broken.
397These two fields are protected by the root <tt>rcu_node</tt>'s
398<tt>->lock</tt> field.
399
400</p><p>There are <tt>->gpnum</tt> and <tt>->completed</tt> fields
401in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
402as well.
403The fields in the <tt>rcu_state</tt> structure represent the
404most current values, and those of the other structures are compared
405in order to detect the start of a new grace period in a distributed
406fashion.
407The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
408(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
409
410<h5>Miscellaneous</h5>
411
412<p>This portion of the <tt>rcu_state</tt> structure is declared
413as follows:
414
415<pre>
416 1 unsigned long gp_max;
417 2 char abbr;
418 3 char *name;
419</pre>
420
421<p>The <tt>->gp_max</tt> field tracks the duration of the longest
422grace period in jiffies.
423It is protected by the root <tt>rcu_node</tt>'s <tt>->lock</tt>.
424
425<p>The <tt>->name</tt> field points to the name of the RCU flavor
426(for example, “rcu_sched”), and is constant.
427The <tt>->abbr</tt> field contains a one-character abbreviation,
428for example, “s” for RCU-sched.
429
430<h3><a name="The rcu_node Structure">
431The <tt>rcu_node</tt> Structure</a></h3>
432
433<p>The <tt>rcu_node</tt> structures form the combining
434tree that propagates quiescent-state
435information from the leaves to the root and also that propagates
436grace-period information from the root down to the leaves.
437They provides local copies of the grace-period state in order
438to allow this information to be accessed in a synchronized
439manner without suffering the scalability limitations that
440would otherwise be imposed by global locking.
441In <tt>CONFIG_PREEMPT_RCU</tt> kernels, they manage the lists
442of tasks that have blocked while in their current
443RCU read-side critical section.
444In <tt>CONFIG_PREEMPT_RCU</tt> with
445<tt>CONFIG_RCU_BOOST</tt>, they manage the
446per-<tt>rcu_node</tt> priority-boosting
447kernel threads (kthreads) and state.
448Finally, they record CPU-hotplug state in order to determine
449which CPUs should be ignored during a given grace period.
450
451</p><p>The <tt>rcu_node</tt> structure's fields are discussed,
452singly and in groups, in the following sections.
453
454<h5>Connection to Combining Tree</h5>
455
456<p>This portion of the <tt>rcu_node</tt> structure is declared
457as follows:
458
459<pre>
460 1 struct rcu_node *parent;
461 2 u8 level;
462 3 u8 grpnum;
463 4 unsigned long grpmask;
464 5 int grplo;
465 6 int grphi;
466</pre>
467
468<p>The <tt>->parent</tt> pointer references the <tt>rcu_node</tt>
469one level up in the tree, and is <tt>NULL</tt> for the root
470<tt>rcu_node</tt>.
471The RCU implementation makes heavy use of this field to push quiescent
472states up the tree.
473The <tt>->level</tt> field gives the level in the tree, with
474the root being at level zero, its children at level one, and so on.
475The <tt>->grpnum</tt> field gives this node's position within
476the children of its parent, so this number can range between 0 and 31
477on 32-bit systems and between 0 and 63 on 64-bit systems.
478The <tt>->level</tt> and <tt>->grpnum</tt> fields are
479used only during initialization and for tracing.
480The <tt>->grpmask</tt> field is the bitmask counterpart of
481<tt>->grpnum</tt>, and therefore always has exactly one bit set.
482This mask is used to clear the bit corresponding to this <tt>rcu_node</tt>
483structure in its parent's bitmasks, which are described later.
484Finally, the <tt>->grplo</tt> and <tt>->grphi</tt> fields
485contain the lowest and highest numbered CPU served by this
486<tt>rcu_node</tt> structure, respectively.
487
488</p><p>All of these fields are constant, and thus do not require any
489synchronization.
490
491<h5>Synchronization</h5>
492
493<p>This field of the <tt>rcu_node</tt> structure is declared
494as follows:
495
496<pre>
497 1 raw_spinlock_t lock;
498</pre>
499
500<p>This field is used to protect the remaining fields in this structure,
501unless otherwise stated.
502That said, all of the fields in this structure can be accessed without
503locking for tracing purposes.
504Yes, this can result in confusing traces, but better some tracing confusion
505than to be heisenbugged out of existence.
506
507<h5>Grace-Period Tracking</h5>
508
509<p>This portion of the <tt>rcu_node</tt> structure is declared
510as follows:
511
512<pre>
513 1 unsigned long gpnum;
514 2 unsigned long completed;
515</pre>
516
517<p>These fields are the counterparts of the fields of the same name in
518the <tt>rcu_state</tt> structure.
519They each may lag up to one behind their <tt>rcu_state</tt>
520counterparts.
521If a given <tt>rcu_node</tt> structure's <tt>->gpnum</tt> and
522<tt>->complete</tt> fields are equal, then this <tt>rcu_node</tt>
523structure believes that RCU is idle.
524Otherwise, as with the <tt>rcu_state</tt> structure,
525the <tt>->gpnum</tt> field will be one greater than the
526<tt>->complete</tt> fields, with <tt>->gpnum</tt>
527indicating which grace period this <tt>rcu_node</tt> believes
528is still being waited for.
529
530</p><p>The <tt>>gpnum</tt> field of each <tt>rcu_node</tt>
531structure is updated at the beginning
532of each grace period, and the <tt>->completed</tt> fields are
533updated at the end of each grace period.
534
535<h5>Quiescent-State Tracking</h5>
536
537<p>These fields manage the propagation of quiescent states up the
538combining tree.
539
540</p><p>This portion of the <tt>rcu_node</tt> structure has fields
541as follows:
542
543<pre>
544 1 unsigned long qsmask;
545 2 unsigned long expmask;
546 3 unsigned long qsmaskinit;
547 4 unsigned long expmaskinit;
548</pre>
549
550<p>The <tt>->qsmask</tt> field tracks which of this
551<tt>rcu_node</tt> structure's children still need to report
552quiescent states for the current normal grace period.
553Such children will have a value of 1 in their corresponding bit.
554Note that the leaf <tt>rcu_node</tt> structures should be
555thought of as having <tt>rcu_data</tt> structures as their
556children.
557Similarly, the <tt>->expmask</tt> field tracks which
558of this <tt>rcu_node</tt> structure's children still need to report
559quiescent states for the current expedited grace period.
560An expedited grace period has
561the same conceptual properties as a normal grace period, but the
562expedited implementation accepts extreme CPU overhead to obtain
563much lower grace-period latency, for example, consuming a few
564tens of microseconds worth of CPU time to reduce grace-period
565duration from milliseconds to tens of microseconds.
566The <tt>->qsmaskinit</tt> field tracks which of this
567<tt>rcu_node</tt> structure's children cover for at least
568one online CPU.
569This mask is used to initialize <tt>->qsmask</tt>,
570and <tt>->expmaskinit</tt> is used to initialize
571<tt>->expmask</tt> and the beginning of the
572normal and expedited grace periods, respectively.
573
574<table>
575<tr><th> </th></tr>
576<tr><th align="left">Quick Quiz:</th></tr>
577<tr><td>
578 Why are these bitmasks protected by locking?
579 Come on, haven't you heard of atomic instructions???
580</td></tr>
581<tr><th align="left">Answer:</th></tr>
582<tr><td bgcolor="#ffffff"><font color="ffffff">
583 Lockless grace-period computation! Such a tantalizing possibility!
584 </font>
585
586 <p><font color="ffffff">But consider the following sequence of events:
587 </font>
588
589 <ol>
590 <li> <font color="ffffff">CPU 0 has been in dyntick-idle
591 mode for quite some time.
592 When it wakes up, it notices that the current RCU
593 grace period needs it to report in, so it sets a
594 flag where the scheduling clock interrupt will find it.
595 </font><p>
596 <li> <font color="ffffff">Meanwhile, CPU 1 is running
597 <tt>force_quiescent_state()</tt>,
598 and notices that CPU 0 has been in dyntick idle mode,
599 which qualifies as an extended quiescent state.
600 </font><p>
601 <li> <font color="ffffff">CPU 0's scheduling clock
602 interrupt fires in the
603 middle of an RCU read-side critical section, and notices
604 that the RCU core needs something, so commences RCU softirq
605 processing.
606 </font>
607 <p>
608 <li> <font color="ffffff">CPU 0's softirq handler
609 executes and is just about ready
610 to report its quiescent state up the <tt>rcu_node</tt>
611 tree.
612 </font><p>
613 <li> <font color="ffffff">But CPU 1 beats it to the punch,
614 completing the current
615 grace period and starting a new one.
616 </font><p>
617 <li> <font color="ffffff">CPU 0 now reports its quiescent
618 state for the wrong
619 grace period.
620 That grace period might now end before the RCU read-side
621 critical section.
622 If that happens, disaster will ensue.
623 </font>
624 </ol>
625
626 <p><font color="ffffff">So the locking is absolutely required in
627 order to coordinate
628 clearing of the bits with the grace-period numbers in
629 <tt>->gpnum</tt> and <tt>->completed</tt>.
630</font></td></tr>
631<tr><td> </td></tr>
632</table>
633
634<h5>Blocked-Task Management</h5>
635
636<p><tt>PREEMPT_RCU</tt> allows tasks to be preempted in the
637midst of their RCU read-side critical sections, and these tasks
638must be tracked explicitly.
639The details of exactly why and how they are tracked will be covered
640in a separate article on RCU read-side processing.
641For now, it is enough to know that the <tt>rcu_node</tt>
642structure tracks them.
643
644<pre>
645 1 struct list_head blkd_tasks;
646 2 struct list_head *gp_tasks;
647 3 struct list_head *exp_tasks;
648 4 bool wait_blkd_tasks;
649</pre>
650
651<p>The <tt>->blkd_tasks</tt> field is a list header for
652the list of blocked and preempted tasks.
653As tasks undergo context switches within RCU read-side critical
654sections, their <tt>task_struct</tt> structures are enqueued
655(via the <tt>task_struct</tt>'s <tt>->rcu_node_entry</tt>
656field) onto the head of the <tt>->blkd_tasks</tt> list for the
657leaf <tt>rcu_node</tt> structure corresponding to the CPU
658on which the outgoing context switch executed.
659As these tasks later exit their RCU read-side critical sections,
660they remove themselves from the list.
661This list is therefore in reverse time order, so that if one of the tasks
662is blocking the current grace period, all subsequent tasks must
663also be blocking that same grace period.
664Therefore, a single pointer into this list suffices to track
665all tasks blocking a given grace period.
666That pointer is stored in <tt>->gp_tasks</tt> for normal
667grace periods and in <tt>->exp_tasks</tt> for expedited
668grace periods.
669These last two fields are <tt>NULL</tt> if either there is
670no grace period in flight or if there are no blocked tasks
671preventing that grace period from completing.
672If either of these two pointers is referencing a task that
673removes itself from the <tt>->blkd_tasks</tt> list,
674then that task must advance the pointer to the next task on
675the list, or set the pointer to <tt>NULL</tt> if there
676are no subsequent tasks on the list.
677
678</p><p>For example, suppose that tasks T1, T2, and T3 are
679all hard-affinitied to the largest-numbered CPU in the system.
680Then if task T1 blocked in an RCU read-side
681critical section, then an expedited grace period started,
682then task T2 blocked in an RCU read-side critical section,
683then a normal grace period started, and finally task 3 blocked
684in an RCU read-side critical section, then the state of the
685last leaf <tt>rcu_node</tt> structure's blocked-task list
686would be as shown below:
687
688</p><p><img src="blkd_task.svg" alt="blkd_task.svg" width="60%">
689
690</p><p>Task T1 is blocking both grace periods, task T2 is
691blocking only the normal grace period, and task T3 is blocking
692neither grace period.
693Note that these tasks will not remove themselves from this list
694immediately upon resuming execution.
695They will instead remain on the list until they execute the outermost
696<tt>rcu_read_unlock()</tt> that ends their RCU read-side critical
697section.
698
699<p>
700The <tt>->wait_blkd_tasks</tt> field indicates whether or not
701the current grace period is waiting on a blocked task.
702
703<h5>Sizing the <tt>rcu_node</tt> Array</h5>
704
705<p>The <tt>rcu_node</tt> array is sized via a series of
706C-preprocessor expressions as follows:
707
708<pre>
709 1 #ifdef CONFIG_RCU_FANOUT
710 2 #define RCU_FANOUT CONFIG_RCU_FANOUT
711 3 #else
712 4 # ifdef CONFIG_64BIT
713 5 # define RCU_FANOUT 64
714 6 # else
715 7 # define RCU_FANOUT 32
716 8 # endif
717 9 #endif
71810
71911 #ifdef CONFIG_RCU_FANOUT_LEAF
72012 #define RCU_FANOUT_LEAF CONFIG_RCU_FANOUT_LEAF
72113 #else
72214 # ifdef CONFIG_64BIT
72315 # define RCU_FANOUT_LEAF 64
72416 # else
72517 # define RCU_FANOUT_LEAF 32
72618 # endif
72719 #endif
72820
72921 #define RCU_FANOUT_1 (RCU_FANOUT_LEAF)
73022 #define RCU_FANOUT_2 (RCU_FANOUT_1 * RCU_FANOUT)
73123 #define RCU_FANOUT_3 (RCU_FANOUT_2 * RCU_FANOUT)
73224 #define RCU_FANOUT_4 (RCU_FANOUT_3 * RCU_FANOUT)
73325
73426 #if NR_CPUS <= RCU_FANOUT_1
73527 # define RCU_NUM_LVLS 1
73628 # define NUM_RCU_LVL_0 1
73729 # define NUM_RCU_NODES NUM_RCU_LVL_0
73830 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0 }
73931 # define RCU_NODE_NAME_INIT { "rcu_node_0" }
74032 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0" }
74133 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0" }
74234 #elif NR_CPUS <= RCU_FANOUT_2
74335 # define RCU_NUM_LVLS 2
74436 # define NUM_RCU_LVL_0 1
74537 # define NUM_RCU_LVL_1 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_1)
74638 # define NUM_RCU_NODES (NUM_RCU_LVL_0 + NUM_RCU_LVL_1)
74739 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0, NUM_RCU_LVL_1 }
74840 # define RCU_NODE_NAME_INIT { "rcu_node_0", "rcu_node_1" }
74941 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0", "rcu_node_fqs_1" }
75042 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0", "rcu_node_exp_1" }
75143 #elif NR_CPUS <= RCU_FANOUT_3
75244 # define RCU_NUM_LVLS 3
75345 # define NUM_RCU_LVL_0 1
75446 # define NUM_RCU_LVL_1 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_2)
75547 # define NUM_RCU_LVL_2 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_1)
75648 # define NUM_RCU_NODES (NUM_RCU_LVL_0 + NUM_RCU_LVL_1 + NUM_RCU_LVL_2)
75749 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0, NUM_RCU_LVL_1, NUM_RCU_LVL_2 }
75850 # define RCU_NODE_NAME_INIT { "rcu_node_0", "rcu_node_1", "rcu_node_2" }
75951 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0", "rcu_node_fqs_1", "rcu_node_fqs_2" }
76052 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0", "rcu_node_exp_1", "rcu_node_exp_2" }
76153 #elif NR_CPUS <= RCU_FANOUT_4
76254 # define RCU_NUM_LVLS 4
76355 # define NUM_RCU_LVL_0 1
76456 # define NUM_RCU_LVL_1 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_3)
76557 # define NUM_RCU_LVL_2 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_2)
76658 # define NUM_RCU_LVL_3 DIV_ROUND_UP(NR_CPUS, RCU_FANOUT_1)
76759 # define NUM_RCU_NODES (NUM_RCU_LVL_0 + NUM_RCU_LVL_1 + NUM_RCU_LVL_2 + NUM_RCU_LVL_3)
76860 # define NUM_RCU_LVL_INIT { NUM_RCU_LVL_0, NUM_RCU_LVL_1, NUM_RCU_LVL_2, NUM_RCU_LVL_3 }
76961 # define RCU_NODE_NAME_INIT { "rcu_node_0", "rcu_node_1", "rcu_node_2", "rcu_node_3" }
77062 # define RCU_FQS_NAME_INIT { "rcu_node_fqs_0", "rcu_node_fqs_1", "rcu_node_fqs_2", "rcu_node_fqs_3" }
77163 # define RCU_EXP_NAME_INIT { "rcu_node_exp_0", "rcu_node_exp_1", "rcu_node_exp_2", "rcu_node_exp_3" }
77264 #else
77365 # error "CONFIG_RCU_FANOUT insufficient for NR_CPUS"
77466 #endif
775</pre>
776
777<p>The maximum number of levels in the <tt>rcu_node</tt> structure
778is currently limited to four, as specified by lines 21-24
779and the structure of the subsequent “if” statement.
780For 32-bit systems, this allows 16*32*32*32=524,288 CPUs, which
781should be sufficient for the next few years at least.
782For 64-bit systems, 16*64*64*64=4,194,304 CPUs is allowed, which
783should see us through the next decade or so.
784This four-level tree also allows kernels built with
785<tt>CONFIG_RCU_FANOUT=8</tt> to support up to 4096 CPUs,
786which might be useful in very large systems having eight CPUs per
787socket (but please note that no one has yet shown any measurable
788performance degradation due to misaligned socket and <tt>rcu_node</tt>
789boundaries).
790In addition, building kernels with a full four levels of <tt>rcu_node</tt>
791tree permits better testing of RCU's combining-tree code.
792
793</p><p>The <tt>RCU_FANOUT</tt> symbol controls how many children
794are permitted at each non-leaf level of the <tt>rcu_node</tt> tree.
795If the <tt>CONFIG_RCU_FANOUT</tt> Kconfig option is not specified,
796it is set based on the word size of the system, which is also
797the Kconfig default.
798
799</p><p>The <tt>RCU_FANOUT_LEAF</tt> symbol controls how many CPUs are
800handled by each leaf <tt>rcu_node</tt> structure.
801Experience has shown that allowing a given leaf <tt>rcu_node</tt>
802structure to handle 64 CPUs, as permitted by the number of bits in
803the <tt>->qsmask</tt> field on a 64-bit system, results in
804excessive contention for the leaf <tt>rcu_node</tt> structures'
805<tt>->lock</tt> fields.
806The number of CPUs per leaf <tt>rcu_node</tt> structure is therefore
807limited to 16 given the default value of <tt>CONFIG_RCU_FANOUT_LEAF</tt>.
808If <tt>CONFIG_RCU_FANOUT_LEAF</tt> is unspecified, the value
809selected is based on the word size of the system, just as for
810<tt>CONFIG_RCU_FANOUT</tt>.
811Lines 11-19 perform this computation.
812
813</p><p>Lines 21-24 compute the maximum number of CPUs supported by
814a single-level (which contains a single <tt>rcu_node</tt> structure),
815two-level, three-level, and four-level <tt>rcu_node</tt> tree,
816respectively, given the fanout specified by <tt>RCU_FANOUT</tt>
817and <tt>RCU_FANOUT_LEAF</tt>.
818These numbers of CPUs are retained in the
819<tt>RCU_FANOUT_1</tt>,
820<tt>RCU_FANOUT_2</tt>,
821<tt>RCU_FANOUT_3</tt>, and
822<tt>RCU_FANOUT_4</tt>
823C-preprocessor variables, respectively.
824
825</p><p>These variables are used to control the C-preprocessor <tt>#if</tt>
826statement spanning lines 26-66 that computes the number of
827<tt>rcu_node</tt> structures required for each level of the tree,
828as well as the number of levels required.
829The number of levels is placed in the <tt>NUM_RCU_LVLS</tt>
830C-preprocessor variable by lines 27, 35, 44, and 54.
831The number of <tt>rcu_node</tt> structures for the topmost level
832of the tree is always exactly one, and this value is unconditionally
833placed into <tt>NUM_RCU_LVL_0</tt> by lines 28, 36, 45, and 55.
834The rest of the levels (if any) of the <tt>rcu_node</tt> tree
835are computed by dividing the maximum number of CPUs by the
836fanout supported by the number of levels from the current level down,
837rounding up. This computation is performed by lines 37,
83846-47, and 56-58.
839Lines 31-33, 40-42, 50-52, and 62-63 create initializers
840for lockdep lock-class names.
841Finally, lines 64-66 produce an error if the maximum number of
842CPUs is too large for the specified fanout.
843
844<h3><a name="The rcu_data Structure">
845The <tt>rcu_data</tt> Structure</a></h3>
846
847<p>The <tt>rcu_data</tt> maintains the per-CPU state for the
848corresponding flavor of RCU.
849The fields in this structure may be accessed only from the corresponding
850CPU (and from tracing) unless otherwise stated.
851This structure is the
852focus of quiescent-state detection and RCU callback queuing.
853It also tracks its relationship to the corresponding leaf
854<tt>rcu_node</tt> structure to allow more-efficient
855propagation of quiescent states up the <tt>rcu_node</tt>
856combining tree.
857Like the <tt>rcu_node</tt> structure, it provides a local
858copy of the grace-period information to allow for-free
859synchronized
860access to this information from the corresponding CPU.
861Finally, this structure records past dyntick-idle state
862for the corresponding CPU and also tracks statistics.
863
864</p><p>The <tt>rcu_data</tt> structure's fields are discussed,
865singly and in groups, in the following sections.
866
867<h5>Connection to Other Data Structures</h5>
868
869<p>This portion of the <tt>rcu_data</tt> structure is declared
870as follows:
871
872<pre>
873 1 int cpu;
874 2 struct rcu_state *rsp;
875 3 struct rcu_node *mynode;
876 4 struct rcu_dynticks *dynticks;
877 5 unsigned long grpmask;
878 6 bool beenonline;
879</pre>
880
881<p>The <tt>->cpu</tt> field contains the number of the
882corresponding CPU, the <tt>->rsp</tt> pointer references
883the corresponding <tt>rcu_state</tt> structure (and is most frequently
884used to locate the name of the corresponding flavor of RCU for tracing),
885and the <tt>->mynode</tt> field references the corresponding
886<tt>rcu_node</tt> structure.
887The <tt>->mynode</tt> is used to propagate quiescent states
888up the combining tree.
889<p>The <tt>->dynticks</tt> pointer references the
890<tt>rcu_dynticks</tt> structure corresponding to this
891CPU.
892Recall that a single per-CPU instance of the <tt>rcu_dynticks</tt>
893structure is shared among all flavors of RCU.
894These first four fields are constant and therefore require not
895synchronization.
896
897</p><p>The <tt>->grpmask</tt> field indicates the bit in
898the <tt>->mynode->qsmask</tt> corresponding to this
899<tt>rcu_data</tt> structure, and is also used when propagating
900quiescent states.
901The <tt>->beenonline</tt> flag is set whenever the corresponding
902CPU comes online, which means that the debugfs tracing need not dump
903out any <tt>rcu_data</tt> structure for which this flag is not set.
904
905<h5>Quiescent-State and Grace-Period Tracking</h5>
906
907<p>This portion of the <tt>rcu_data</tt> structure is declared
908as follows:
909
910<pre>
911 1 unsigned long completed;
912 2 unsigned long gpnum;
913 3 bool cpu_no_qs;
914 4 bool core_needs_qs;
915 5 bool gpwrap;
916 6 unsigned long rcu_qs_ctr_snap;
917</pre>
918
919<p>The <tt>completed</tt> and <tt>gpnum</tt>
920fields are the counterparts of the fields of the same name
921in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures.
922They may each lag up to one behind their <tt>rcu_node</tt>
923counterparts, but in <tt>CONFIG_NO_HZ_IDLE</tt> and
924<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
925arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
926will catch up upon exit from dyntick-idle mode).
927If a given <tt>rcu_data</tt> structure's <tt>->gpnum</tt> and
928<tt>->complete</tt> fields are equal, then this <tt>rcu_data</tt>
929structure believes that RCU is idle.
930Otherwise, as with the <tt>rcu_state</tt> and <tt>rcu_node</tt>
931structure,
932the <tt>->gpnum</tt> field will be one greater than the
933<tt>->complete</tt> fields, with <tt>->gpnum</tt>
934indicating which grace period this <tt>rcu_data</tt> believes
935is still being waited for.
936
937<table>
938<tr><th> </th></tr>
939<tr><th align="left">Quick Quiz:</th></tr>
940<tr><td>
941 All this replication of the grace period numbers can only cause
942 massive confusion.
943 Why not just keep a global pair of counters and be done with it???
944</td></tr>
945<tr><th align="left">Answer:</th></tr>
946<tr><td bgcolor="#ffffff"><font color="ffffff">
947 Because if there was only a single global pair of grace-period
948 numbers, there would need to be a single global lock to allow
949 safely accessing and updating them.
950 And if we are not going to have a single global lock, we need
951 to carefully manage the numbers on a per-node basis.
952 Recall from the answer to a previous Quick Quiz that the consequences
953 of applying a previously sampled quiescent state to the wrong
954 grace period are quite severe.
955</font></td></tr>
956<tr><td> </td></tr>
957</table>
958
959<p>The <tt>->cpu_no_qs</tt> flag indicates that the
960CPU has not yet passed through a quiescent state,
961while the <tt>->core_needs_qs</tt> flag indicates that the
962RCU core needs a quiescent state from the corresponding CPU.
963The <tt>->gpwrap</tt> field indicates that the corresponding
964CPU has remained idle for so long that the <tt>completed</tt>
965and <tt>gpnum</tt> counters are in danger of overflow, which
966will cause the CPU to disregard the values of its counters on
967its next exit from idle.
968Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
969cases where a given operation has resulted in a quiescent state
970for all flavors of RCU, for example, <tt>cond_resched_rcu_qs()</tt>.
971
972<h5>RCU Callback Handling</h5>
973
974<p>In the absence of CPU-hotplug events, RCU callbacks are invoked by
975the same CPU that registered them.
976This is strictly a cache-locality optimization: callbacks can and
977do get invoked on CPUs other than the one that registered them.
978After all, if the CPU that registered a given callback has gone
979offline before the callback can be invoked, there really is no other
980choice.
981
982</p><p>This portion of the <tt>rcu_data</tt> structure is declared
983as follows:
984
985<pre>
986 1 struct rcu_head *nxtlist;
987 2 struct rcu_head **nxttail[RCU_NEXT_SIZE];
988 3 unsigned long nxtcompleted[RCU_NEXT_SIZE];
989 4 long qlen_lazy;
990 5 long qlen;
991 6 long qlen_last_fqs_check;
992 7 unsigned long n_force_qs_snap;
993 8 unsigned long n_cbs_invoked;
994 9 unsigned long n_cbs_orphaned;
99510 unsigned long n_cbs_adopted;
99611 long blimit;
997</pre>
998
999<p>The <tt>->nxtlist</tt> pointer and the
1000<tt>->nxttail[]</tt> array form a four-segment list with
1001older callbacks near the head and newer ones near the tail.
1002Each segment contains callbacks with the corresponding relationship
1003to the current grace period.
1004The pointer out of the end of each of the four segments is referenced
1005by the element of the <tt>->nxttail[]</tt> array indexed by
1006<tt>RCU_DONE_TAIL</tt> (for callbacks handled by a prior grace period),
1007<tt>RCU_WAIT_TAIL</tt> (for callbacks waiting on the current grace period),
1008<tt>RCU_NEXT_READY_TAIL</tt> (for callbacks that will wait on the next
1009grace period), and
1010<tt>RCU_NEXT_TAIL</tt> (for callbacks that are not yet associated
1011with a specific grace period)
1012respectively, as shown in the following figure.
1013
1014</p><p><img src="nxtlist.svg" alt="nxtlist.svg" width="40%">
1015
1016</p><p>In this figure, the <tt>->nxtlist</tt> pointer references the
1017first
1018RCU callback in the list.
1019The <tt>->nxttail[RCU_DONE_TAIL]</tt> array element references
1020the <tt>->nxtlist</tt> pointer itself, indicating that none
1021of the callbacks is ready to invoke.
1022The <tt>->nxttail[RCU_WAIT_TAIL]</tt> array element references callback
1023CB 2's <tt>->next</tt> pointer, which indicates that
1024CB 1 and CB 2 are both waiting on the current grace period.
1025The <tt>->nxttail[RCU_NEXT_READY_TAIL]</tt> array element
1026references the same RCU callback that <tt>->nxttail[RCU_WAIT_TAIL]</tt>
1027does, which indicates that there are no callbacks waiting on the next
1028RCU grace period.
1029The <tt>->nxttail[RCU_NEXT_TAIL]</tt> array element references
1030CB 4's <tt>->next</tt> pointer, indicating that all the
1031remaining RCU callbacks have not yet been assigned to an RCU grace
1032period.
1033Note that the <tt>->nxttail[RCU_NEXT_TAIL]</tt> array element
1034always references the last RCU callback's <tt>->next</tt> pointer
1035unless the callback list is empty, in which case it references
1036the <tt>->nxtlist</tt> pointer.
1037
1038</p><p>CPUs advance their callbacks from the
1039<tt>RCU_NEXT_TAIL</tt> to the <tt>RCU_NEXT_READY_TAIL</tt> to the
1040<tt>RCU_WAIT_TAIL</tt> to the <tt>RCU_DONE_TAIL</tt> list segments
1041as grace periods advance.
1042The CPU advances the callbacks in its <tt>rcu_data</tt> structure
1043whenever it notices that another RCU grace period has completed.
1044The CPU detects the completion of an RCU grace period by noticing
1045that the value of its <tt>rcu_data</tt> structure's
1046<tt>->completed</tt> field differs from that of its leaf
1047<tt>rcu_node</tt> structure.
1048Recall that each <tt>rcu_node</tt> structure's
1049<tt>->completed</tt> field is updated at the end of each
1050grace period.
1051
1052</p><p>The <tt>->nxtcompleted[]</tt> array records grace-period
1053numbers corresponding to the list segments.
1054This allows CPUs that go idle for extended periods to determine
1055which of their callbacks are ready to be invoked after reawakening.
1056
1057</p><p>The <tt>->qlen</tt> counter contains the number of
1058callbacks in <tt>->nxtlist</tt>, and the
1059<tt>->qlen_lazy</tt> contains the number of those callbacks that
1060are known to only free memory, and whose invocation can therefore
1061be safely deferred.
1062The <tt>->qlen_last_fqs_check</tt> and
1063<tt>->n_force_qs_snap</tt> coordinate the forcing of quiescent
1064states from <tt>call_rcu()</tt> and friends when callback
1065lists grow excessively long.
1066
1067</p><p>The <tt>->n_cbs_invoked</tt>,
1068<tt>->n_cbs_orphaned</tt>, and <tt>->n_cbs_adopted</tt>
1069fields count the number of callbacks invoked,
1070sent to other CPUs when this CPU goes offline,
1071and received from other CPUs when those other CPUs go offline.
1072Finally, the <tt>->blimit</tt> counter is the maximum number of
1073RCU callbacks that may be invoked at a given time.
1074
1075<h5>Dyntick-Idle Handling</h5>
1076
1077<p>This portion of the <tt>rcu_data</tt> structure is declared
1078as follows:
1079
1080<pre>
1081 1 int dynticks_snap;
1082 2 unsigned long dynticks_fqs;
1083</pre>
1084
1085The <tt>->dynticks_snap</tt> field is used to take a snapshot
1086of the corresponding CPU's dyntick-idle state when forcing
1087quiescent states, and is therefore accessed from other CPUs.
1088Finally, the <tt>->dynticks_fqs</tt> field is used to
1089count the number of times this CPU is determined to be in
1090dyntick-idle state, and is used for tracing and debugging purposes.
1091
1092<h3><a name="The rcu_dynticks Structure">
1093The <tt>rcu_dynticks</tt> Structure</a></h3>
1094
1095<p>The <tt>rcu_dynticks</tt> maintains the per-CPU dyntick-idle state
1096for the corresponding CPU.
1097Unlike the other structures, <tt>rcu_dynticks</tt> is not
1098replicated over the different flavors of RCU.
1099The fields in this structure may be accessed only from the corresponding
1100CPU (and from tracing) unless otherwise stated.
1101Its fields are as follows:
1102
1103<pre>
1104 1 int dynticks_nesting;
1105 2 int dynticks_nmi_nesting;
1106 3 atomic_t dynticks;
1107</pre>
1108
1109<p>The <tt>->dynticks_nesting</tt> field counts the
1110nesting depth of normal interrupts.
1111In addition, this counter is incremented when exiting dyntick-idle
1112mode and decremented when entering it.
1113This counter can therefore be thought of as counting the number
1114of reasons why this CPU cannot be permitted to enter dyntick-idle
1115mode, aside from non-maskable interrupts (NMIs).
1116NMIs are counted by the <tt>->dynticks_nmi_nesting</tt>
1117field, except that NMIs that interrupt non-dyntick-idle execution
1118are not counted.
1119
1120</p><p>Finally, the <tt>->dynticks</tt> field counts the corresponding
1121CPU's transitions to and from dyntick-idle mode, so that this counter
1122has an even value when the CPU is in dyntick-idle mode and an odd
1123value otherwise.
1124
1125<table>
1126<tr><th> </th></tr>
1127<tr><th align="left">Quick Quiz:</th></tr>
1128<tr><td>
1129 Why not just count all NMIs?
1130 Wouldn't that be simpler and less error prone?
1131</td></tr>
1132<tr><th align="left">Answer:</th></tr>
1133<tr><td bgcolor="#ffffff"><font color="ffffff">
1134 It seems simpler only until you think hard about how to go about
1135 updating the <tt>rcu_dynticks</tt> structure's
1136 <tt>->dynticks</tt> field.
1137</font></td></tr>
1138<tr><td> </td></tr>
1139</table>
1140
1141<p>Additional fields are present for some special-purpose
1142builds, and are discussed separately.
1143
1144<h3><a name="The rcu_head Structure">
1145The <tt>rcu_head</tt> Structure</a></h3>
1146
1147<p>Each <tt>rcu_head</tt> structure represents an RCU callback.
1148These structures are normally embedded within RCU-protected data
1149structures whose algorithms use asynchronous grace periods.
1150In contrast, when using algorithms that block waiting for RCU grace periods,
1151RCU users need not provide <tt>rcu_head</tt> structures.
1152
1153</p><p>The <tt>rcu_head</tt> structure has fields as follows:
1154
1155<pre>
1156 1 struct rcu_head *next;
1157 2 void (*func)(struct rcu_head *head);
1158</pre>
1159
1160<p>The <tt>->next</tt> field is used
1161to link the <tt>rcu_head</tt> structures together in the
1162lists within the <tt>rcu_data</tt> structures.
1163The <tt>->func</tt> field is a pointer to the function
1164to be called when the callback is ready to be invoked, and
1165this function is passed a pointer to the <tt>rcu_head</tt>
1166structure.
1167However, <tt>kfree_rcu()</tt> uses the <tt>->func</tt>
1168field to record the offset of the <tt>rcu_head</tt>
1169structure within the enclosing RCU-protected data structure.
1170
1171</p><p>Both of these fields are used internally by RCU.
1172From the viewpoint of RCU users, this structure is an
1173opaque “cookie”.
1174
1175<table>
1176<tr><th> </th></tr>
1177<tr><th align="left">Quick Quiz:</th></tr>
1178<tr><td>
1179 Given that the callback function <tt>->func</tt>
1180 is passed a pointer to the <tt>rcu_head</tt> structure,
1181 how is that function supposed to find the beginning of the
1182 enclosing RCU-protected data structure?
1183</td></tr>
1184<tr><th align="left">Answer:</th></tr>
1185<tr><td bgcolor="#ffffff"><font color="ffffff">
1186 In actual practice, there is a separate callback function per
1187 type of RCU-protected data structure.
1188 The callback function can therefore use the <tt>container_of()</tt>
1189 macro in the Linux kernel (or other pointer-manipulation facilities
1190 in other software environments) to find the beginning of the
1191 enclosing structure.
1192</font></td></tr>
1193<tr><td> </td></tr>
1194</table>
1195
1196<h3><a name="RCU-Specific Fields in the task_struct Structure">
1197RCU-Specific Fields in the <tt>task_struct</tt> Structure</a></h3>
1198
1199<p>The <tt>CONFIG_PREEMPT_RCU</tt> implementation uses some
1200additional fields in the <tt>task_struct</tt> structure:
1201
1202<pre>
1203 1 #ifdef CONFIG_PREEMPT_RCU
1204 2 int rcu_read_lock_nesting;
1205 3 union rcu_special rcu_read_unlock_special;
1206 4 struct list_head rcu_node_entry;
1207 5 struct rcu_node *rcu_blocked_node;
1208 6 #endif /* #ifdef CONFIG_PREEMPT_RCU */
1209 7 #ifdef CONFIG_TASKS_RCU
1210 8 unsigned long rcu_tasks_nvcsw;
1211 9 bool rcu_tasks_holdout;
121210 struct list_head rcu_tasks_holdout_list;
121311 int rcu_tasks_idle_cpu;
121412 #endif /* #ifdef CONFIG_TASKS_RCU */
1215</pre>
1216
1217<p>The <tt>->rcu_read_lock_nesting</tt> field records the
1218nesting level for RCU read-side critical sections, and
1219the <tt>->rcu_read_unlock_special</tt> field is a bitmask
1220that records special conditions that require <tt>rcu_read_unlock()</tt>
1221to do additional work.
1222The <tt>->rcu_node_entry</tt> field is used to form lists of
1223tasks that have blocked within preemptible-RCU read-side critical
1224sections and the <tt>->rcu_blocked_node</tt> field references
1225the <tt>rcu_node</tt> structure whose list this task is a member of,
1226or <tt>NULL</tt> if it is not blocked within a preemptible-RCU
1227read-side critical section.
1228
1229<p>The <tt>->rcu_tasks_nvcsw</tt> field tracks the number of
1230voluntary context switches that this task had undergone at the
1231beginning of the current tasks-RCU grace period,
1232<tt>->rcu_tasks_holdout</tt> is set if the current tasks-RCU
1233grace period is waiting on this task, <tt>->rcu_tasks_holdout_list</tt>
1234is a list element enqueuing this task on the holdout list,
1235and <tt>->rcu_tasks_idle_cpu</tt> tracks which CPU this
1236idle task is running, but only if the task is currently running,
1237that is, if the CPU is currently idle.
1238
1239<h3><a name="Accessor Functions">
1240Accessor Functions</a></h3>
1241
1242<p>The following listing shows the
1243<tt>rcu_get_root()</tt>, <tt>rcu_for_each_node_breadth_first</tt>,
1244<tt>rcu_for_each_nonleaf_node_breadth_first()</tt>, and
1245<tt>rcu_for_each_leaf_node()</tt> function and macros:
1246
1247<pre>
1248 1 static struct rcu_node *rcu_get_root(struct rcu_state *rsp)
1249 2 {
1250 3 return &rsp->node[0];
1251 4 }
1252 5
1253 6 #define rcu_for_each_node_breadth_first(rsp, rnp) \
1254 7 for ((rnp) = &(rsp)->node[0]; \
1255 8 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++)
1256 9
1257 10 #define rcu_for_each_nonleaf_node_breadth_first(rsp, rnp) \
1258 11 for ((rnp) = &(rsp)->node[0]; \
1259 12 (rnp) < (rsp)->level[NUM_RCU_LVLS - 1]; (rnp)++)
1260 13
1261 14 #define rcu_for_each_leaf_node(rsp, rnp) \
1262 15 for ((rnp) = (rsp)->level[NUM_RCU_LVLS - 1]; \
1263 16 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++)
1264</pre>
1265
1266<p>The <tt>rcu_get_root()</tt> simply returns a pointer to the
1267first element of the specified <tt>rcu_state</tt> structure's
1268<tt>->node[]</tt> array, which is the root <tt>rcu_node</tt>
1269structure.
1270
1271</p><p>As noted earlier, the <tt>rcu_for_each_node_breadth_first()</tt>
1272macro takes advantage of the layout of the <tt>rcu_node</tt>
1273structures in the <tt>rcu_state</tt> structure's
1274<tt>->node[]</tt> array, performing a breadth-first traversal by
1275simply traversing the array in order.
1276The <tt>rcu_for_each_nonleaf_node_breadth_first()</tt> macro operates
1277similarly, but traverses only the first part of the array, thus excluding
1278the leaf <tt>rcu_node</tt> structures.
1279Finally, the <tt>rcu_for_each_leaf_node()</tt> macro traverses only
1280the last part of the array, thus traversing only the leaf
1281<tt>rcu_node</tt> structures.
1282
1283<table>
1284<tr><th> </th></tr>
1285<tr><th align="left">Quick Quiz:</th></tr>
1286<tr><td>
1287 What do <tt>rcu_for_each_nonleaf_node_breadth_first()</tt> and
1288 <tt>rcu_for_each_leaf_node()</tt> do if the <tt>rcu_node</tt> tree
1289 contains only a single node?
1290</td></tr>
1291<tr><th align="left">Answer:</th></tr>
1292<tr><td bgcolor="#ffffff"><font color="ffffff">
1293 In the single-node case,
1294 <tt>rcu_for_each_nonleaf_node_breadth_first()</tt> is a no-op
1295 and <tt>rcu_for_each_leaf_node()</tt> traverses the single node.
1296</font></td></tr>
1297<tr><td> </td></tr>
1298</table>
1299
1300<h3><a name="Summary">
1301Summary</a></h3>
1302
1303So each flavor of RCU is represented by an <tt>rcu_state</tt> structure,
1304which contains a combining tree of <tt>rcu_node</tt> and
1305<tt>rcu_data</tt> structures.
1306Finally, in <tt>CONFIG_NO_HZ_IDLE</tt> kernels, each CPU's dyntick-idle
1307state is tracked by an <tt>rcu_dynticks</tt> structure.
1308
1309If you made it this far, you are well prepared to read the code
1310walkthroughs in the other articles in this series.
1311
1312<h3><a name="Acknowledgments">
1313Acknowledgments</a></h3>
1314
1315I owe thanks to Cyrill Gorcunov, Mathieu Desnoyers, Dhaval Giani, Paul
1316Turner, Abhishek Srivastava, Matt Kowalczyk, and Serge Hallyn
1317for helping me get this document into a more human-readable state.
1318
1319<h3><a name="Legal Statement">
1320Legal Statement</a></h3>
1321
1322<p>This work represents the view of the author and does not necessarily
1323represent the view of IBM.
1324
1325</p><p>Linux is a registered trademark of Linus Torvalds.
1326
1327</p><p>Other company, product, and service names may be trademarks or
1328service marks of others.
1329
1330</body></html>