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