The rcu_irq_enter() and rcu_irq_exit() functions handle interrupt/NMI entry and exit, respectively. Of course, nested interrupts must also be properly accounted for. The possibility of nested interrupts is handled by a second per-CPU variable, rcu_update_flag, which is incremented upon entry to an interrupt or NMI handler (in rcu_irq_enter()) and is decremented upon exit (in rcu_irq_exit()). In addition, the pre-existing in_interrupt() primitive is used to distinguish between an outermost or a nested interrupt/NMI.
Interrupt entry is handled by the rcu_irq_enter shown below:
1 void rcu_irq_enter(void) 2 { 3 int cpu = smp_processor_id(); 4 5 if (per_cpu(rcu_update_flag, cpu)) 6 per_cpu(rcu_update_flag, cpu)++; 7 if (!in_interrupt() && 8 (per_cpu(dynticks_progress_counter, 9 cpu) & 0x1) == 0) { 10 per_cpu(dynticks_progress_counter, cpu)++; 11 smp_mb(); 12 per_cpu(rcu_update_flag, cpu)++; 13 } 14 }
Line 3 fetches the current CPU's number, while lines 5 and 6 increment the rcu_update_flag nesting counter if it is already non-zero. Lines 7-9 check to see whether we are the outermost level of interrupt, and, if so, whether dynticks_progress_counter needs to be incremented. If so, line 10 increments dynticks_progress_counter, line 11 executes a memory barrier, and line 12 increments rcu_update_flag. As with rcu_exit_nohz(), the memory barrier ensures that any other CPU that sees the effects of an RCU read-side critical section in the interrupt handler (following the rcu_irq_enter() invocation) will also see the increment of dynticks_progress_counter.
Quick Quiz E.7: Why not simply increment rcu_update_flag, and then only increment dynticks_progress_counter if the old value of rcu_update_flag was zero??? End Quick Quiz
Quick Quiz E.8: But if line 7 finds that we are the outermost interrupt, wouldn't we always need to increment dynticks_progress_counter? End Quick Quiz
Interrupt exit is handled similarly by rcu_irq_exit():
1 void rcu_irq_exit(void) 2 { 3 int cpu = smp_processor_id(); 4 5 if (per_cpu(rcu_update_flag, cpu)) { 6 if (--per_cpu(rcu_update_flag, cpu)) 7 return; 8 WARN_ON(in_interrupt()); 9 smp_mb(); 10 per_cpu(dynticks_progress_counter, cpu)++; 11 WARN_ON(per_cpu(dynticks_progress_counter, 12 cpu) & 0x1); 13 } 14 }
Line 3 fetches the current CPU's number, as before. Line 5 checks to see if the rcu_update_flag is non-zero, returning immediately (via falling off the end of the function) if not. Otherwise, lines 6 through 12 come into play. Line 6 decrements rcu_update_flag, returning if the result is not zero. Line 8 verifies that we are indeed leaving the outermost level of nested interrupts, line 9 executes a memory barrier, line 10 increments dynticks_progress_counter, and lines 11 and 12 verify that this variable is now even. As with rcu_enter_nohz(), the memory barrier ensures that any other CPU that sees the increment of dynticks_progress_counter will also see the effects of an RCU read-side critical section in the interrupt handler (preceding the rcu_irq_exit() invocation).
These two sections have described how the dynticks_progress_counter variable is maintained during entry to and exit from dynticks-idle mode, both by tasks and by interrupts and NMIs. The following section describes how this variable is used by preemptible RCU's grace-period machinery.
Paul E. McKenney 2011-12-16