D.3.8 Forcing Quiescent States

Normally, CPUs pass through quiescent states which are duly recorded, so that grace periods end in a timely manner. However, any of the following three conditions can prevent CPUs from passing through quiescent states:

  1. The CPU is in dyntick-idle state, and is sleeping in a low-power mode. Although such a CPU is officially in an extended quiescent state, because it is not executing instructions, it cannot do anything on its own.
  2. The CPU is in the process of coming online, and RCU has been informed that it is online, but this CPU is not yet actually executing code, nor is it marked as online in cpu_online_map. The current grace period will therefore wait on it, but it cannot yet pass through quiescent states on its own.
  3. The CPU is running user-level code, but has avoided entering the scheduler for an extended time period.

In each of these cases, RCU needs to take action on behalf of the non-responding CPU. The following sections describe the functions that take such action. Section [*] describes the functions that record and recall the dynticks-idle grace-period number (in order to avoid incorrectly applying a dynticks-idle quiescent state to the wrong grace period), Section [*] describes functions that detect offline and holdout CPUs, Section [*] covers rcu_process_dyntick(), which scans for holdout CPUs, and Section [*] describes force_quiescent_state(), which drives the process of detecting extended quiescent states and forcing quiescent states on holdout CPUs.



Subsections
Paul E. McKenney 2011-12-16