D.3.1.2 Nodes in the Hierarchy
Keywords: perfbook_html

###
D.3.1.2 Nodes in the Hierarchy

As noted earlier, the rcu_node hierarchy is flattened into the rcu_state structure as shown in Figure on page . Each rcu_node in this hierarchy has fields as follows:

- lock: This spinlock guards the non-constant fields in this structure. This lock is acquired from softirq context, so must disable irqs.

  Quick Quiz D.19: Why not simply disable bottom halves (softirq) when acquiring the rcu_data structure's lock? Wouldn't this be faster? End Quick Quiz

  The lock field of the root rcu_node has additional responsibilities:

  1. Serializes CPU-stall checking, so that a given stall is reported by only one CPU. This can be important on systems with thousands of CPUs!
  2. Serializes starting a new grace period, so that multiple CPUs don't start conflicting grace periods concurrently.
  3. Prevents new grace periods from starting in code that needs to run within the confines of a single grace period.
  4. Serializes the state machine forcing quiescent states (in force_quiescent_state()) in order to keep the number of reschedule IPIs down to a dull roar.
- qsmask: This bitmask tracks which CPUs (for leaf rcu_node structures) or groups of CPUs (for non-leaf rcu_node structures) still need to pass through a quiescent state in order for the current grace period to end.
- qsmaskinit: This bitmask tracks which CPUs or groups of CPUs will need to pass through a quiescent state for subsequent grace periods to end. The online/offline code manipulates the qsmaskinit fields, which are copied to the corresponding qsmask fields at the beginning of each grace period. This copy operation is one reason why grace period initialization must exclude online/offline operations.
- grpmask: This bitmask has a single bit set, and that is the bit corresponding to the this rcu_node structure's position in the parent rcu_node structure's qsmask and qsmaskinit fields. Use of this field simplifies quiescent-state processing, as suggested by Manfred Spraul.

  Quick Quiz D.20: How about the qsmask and qsmaskinit fields for the leaf rcu_node structures? Doesn't there have to be some way to work out which of the bits in these fields corresponds to each CPU covered by the rcu_node structure in question? End Quick Quiz

- grplo: This field contains the number of the lowest-numbered CPU covered by this rcu_node structure.
- grphi: This field contains the number of the highest-numbered CPU covered by this rcu_node structure.
- grpnum: This field contains the bit number in the parent rcu_node structure's qsmask and qsmaskinit fields that this rcu_node structure corresponds to. In other words, given a pointer rnp to a given rcu_node structure, it will always be the case that 1UL « rnp->grpnum == rnp->grpmask. The grpnum field is used only for tracing output.
- level: This field contains zero for the root rcu_node structure, one for the rcu_node structures that are children of the root, and so on down the hierarchy.
- parent: This field is a pointer to the parent rcu_node structure, or NULL for the root rcu_node structure.