···357357grace-period initialization.358358359359<p>The first ordering-related grace-period initialization action is to360360-increment the <tt>rcu_state</tt> structure's <tt>->gpnum</tt>360360+advance the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt>361361grace-period-number counter, as shown below:362362363363</p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">···388388389389<p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>390390tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's391391-<tt>->gpnum</tt> field to the newly incremented value from the391391+<tt>->gp_seq</tt> field to the newly advanced value from the392392<tt>rcu_state</tt> structure, as shown in the following diagram.393393394394</p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">···398398to notice that a new grace period has started, as described in the next399399section.400400But because the grace-period kthread started the grace period at the401401-root (with the increment of the <tt>rcu_state</tt> structure's402402-<tt>->gpnum</tt> field) before setting each leaf <tt>rcu_node</tt>403403-structure's <tt>->gpnum</tt> field, each CPU's observation of401401+root (with the advancing of the <tt>rcu_state</tt> structure's402402+<tt>->gp_seq</tt> field) before setting each leaf <tt>rcu_node</tt>403403+structure's <tt>->gp_seq</tt> field, each CPU's observation of404404the start of the grace period will happen after the actual start405405of the grace period.406406···466466<tr><td>467467 But a RCU read-side critical section might have started468468 after the beginning of the grace period469469- (the <tt>->gpnum++</tt> from earlier), so why should469469+ (the advancing of <tt>->gp_seq</tt> from earlier), so why should470470 the grace period wait on such a critical section?471471</td></tr>472472<tr><th align="left">Answer:</th></tr>···609609<h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>610610611611<p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree612612-breadth-first setting all the <tt>->completed</tt> fields equal613613-to the number of the newly completed grace period, then it sets614614-the <tt>rcu_state</tt> structure's <tt>->completed</tt> field,615615-again to the number of the newly completed grace period.612612+breadth-first advancing all the <tt>->gp_seq</tt> fields, then it613613+advances the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt> field.616614The ordering effects are shown below:617615618616</p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">···632634 CPU has reported its quiescent state, but it may be some633635 milliseconds before RCU becomes aware of this.634636 The latest reasonable candidate is once the <tt>rcu_state</tt>635635- structure's <tt>->completed</tt> field has been updated,637637+ structure's <tt>->gp_seq</tt> field has been updated,636638 but it is quite possible that some CPUs have already completed637639 phase two of their updates by that time.638640 In short, if you are going to work with RCU, you need to···645647<h4><a name="Callback Invocation">Callback Invocation</a></h4>646648647649<p>Once a given CPU's leaf <tt>rcu_node</tt> structure's648648-<tt>->completed</tt> field has been updated, that CPU can begin650650+<tt>->gp_seq</tt> field has been updated, that CPU can begin649651invoking its RCU callbacks that were waiting for this grace period650652to end.651653These callbacks are identified by <tt>rcu_advance_cbs()</tt>,