Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst

156    the ``rcu_node`` structure's ``->expmaskinitnext`` field. The
157    ``rcu_node`` structure's ``->expmaskinit`` field tracks the
162    that is, when the ``rcu_node`` structure's ``->expmaskinitnext``
164    period, which triggers an update of each ``rcu_node`` structure's
166 #. Each ``rcu_node`` structure's ``->expmaskinit`` field is used to
171 #. Any CPU that goes offline will clear its bit in its leaf ``rcu_node``
215 | bitmasks in the ``rcu_node`` tree.                                    |
289 the expedited grace period is to use the ``rcu_node`` combining tree, as
291 corresponding to a given grace period arriving at a given ``rcu_node``
298 ``->exp_lock`` field in the ``rcu_node`` structure synchronizes access
301 An empty ``rcu_node`` tree is shown in the following diagram, with the
308 Task B at the leftmost and rightmost leaf ``rcu_node`` structures,
312 ``->exp_seq_rq`` field of their respective ``rcu_node`` structures:
316 Each of Tasks A and B will move up to the root ``rcu_node`` structure.
323 up to the root ``rcu_node`` structure, and, seeing that its desired
345 ``rcu_node`` structures already have that value recorded. They will
346 therefore block on their respective ``rcu_node`` structures'
358 Tasks E and F will propagate up the ``rcu_node`` combining tree, with
359 Task F blocking on the root ``rcu_node`` structure and Task E wait for
379 Note that three of the root ``rcu_node`` structure's waitqueues are now
455 ``rcu_node`` structures blocking the current grace period are printed.
500 the group will block on waitqueues provided in the ``rcu_node``
511 Quiescent states are tracked using the ``rcu_node`` tree, and once all