Documentation/RCU/Design/Data-Structures/Data-Structures.html

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