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

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