D.3.7.3 Interrupts from Dyntick-Idle Mode
Keywords: perfbook_html

###
D.3.7.3 Interrupts from Dyntick-Idle Mode

Figure: Interrupts from Dyntick-Idle Mode

Figure shows rcu_irq_enter() and rcu_irq_exit(), which handle interrupt entry and exit, respectively. As with NMIs, it is important to note that entering an interrupt handler exits dyntick-idle mode and vice versa, due to the fact that RCU read-side critical sections can appear in interrupt handlers.

Line 5 of rcu_irq_enter() once again acquires a reference to the current CPU's rcu_dynticks structure. Line 6 increments the ->dynticks_nesting field, and if the original value was already non-zero (in other words, RCU was already paying attention to this CPU), line 7 silently returns. Otherwise, line 8 increments the ->dynticks field, which then must have an odd-numbered value. Finally, line 9 executes a memory barrier so that this increment is seen by all CPUs as happening before any RCU read-side critical sections that might be in the interrupt handler.

Line 16 of rcu_irq_exit() does the by-now traditional acquisition of a reference to the currently running CPU's rcu_dynticks structure. Line 17 decrements the ->dynticks_nesting field, and, if the result is non-zero (in other words, RCU must still pay attention to this CPU despite exiting this interrupt handler), then line 18 silently returns. Otherwise, line 19 executes a memory barrier so that any RCU read-side critical sections that might have been in the interrupt handler are seen by all CPUs as having happened before the increment on line 20 of the ->dynticks field (which must now have an even-numbered value). Lines 21 and 22 check to see if the interrupt handler posted any ``rcu'' or ``rcu_bh'' callbacks, and, if so, line 23 forces this CPU to reschedule, which has the side-effect of forcing it out of dynticks-idle mode, as is required to allow RCU to handle the grace period required by these callbacks.