D.3.2.2 call_rcu()
Keywords: perfbook_html

###
D.3.2.2 `call_rcu()`

Figure: `call_rcu()` Code

Figure shows the code for __call_rcu(), call_rcu(), and call_rcu_bh(). Note that call_rcu() and call_rcu_bh() are simple wrappers for call_rcu(), and thus will not be considered further here.

Turning attention to __call_rcu(), lines 9-10 initialize the specified rcu_head, and line 11 ensures that updates to RCU-protected data structures carried out prior to invoking __call_rcu() are seen prior to callback registry. Lines 12 and 34 disable and re-enable interrupts to prevent destructive interference by any calls to __call_rcu() from an interrupt handler. Line 13 obtains a reference to the current CPU's rcu_data structure, line 14 invokes rcu_process_gp_end() in order to advance callbacks if the current grace period has now ended, while line 15 invokes check_for_new_grace_period() to record state if a new grace period has started.

Quick Quiz D.28: Why not simply use __get_cpu_var() to pick up a reference to the current CPU's rcu_data structure on line 13 in Figure ? End Quick Quiz

Lines 16 and 17 enqueue the new callback. Lines 18 and 19 check to see there is a grace period in progress, and, if not, line 23 acquires the root rcu_node structure's lock and line 24 invokes rcu_start_gp() to start a new grace period (and also to release the lock).

Line 26 checks to see if too many RCU callbacks are waiting on this CPU, and, if so, line 27 increases ->blimit in order to increase the rate at which callbacks are processed, while line 28 invokes force_quiescent_state() urgently in order to try to convince holdout CPUs to pass through quiescent states. Otherwise, lines 29-32 check to see if it has been too long since the grace period started (or since the last call to force_quiescent_state(), as the case may be), and, if so, line 33 invokes force_quiescent_state() non-urgently, again to convince holdout CPUs to pass through quiescent states.