|author||Paul E. McKenney <firstname.lastname@example.org>||2012-12-28 11:30:36 -0800|
|committer||Paul E. McKenney <email@example.com>||2013-03-26 08:04:51 -0700|
rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks
Because RCU callbacks are now associated with the number of the grace period that they must wait for, CPUs can now take advance callbacks corresponding to grace periods that ended while a given CPU was in dyntick-idle mode. This eliminates the need to try forcing the RCU state machine while entering idle, thus reducing the CPU intensiveness of RCU_FAST_NO_HZ, which should increase its energy efficiency. Signed-off-by: Paul E. McKenney <firstname.lastname@example.org> Signed-off-by: Paul E. McKenney <email@example.com>
Diffstat (limited to 'init')
1 files changed, 10 insertions, 7 deletions
diff --git a/init/Kconfig b/init/Kconfig
index 717584064a7..a3a2304fa6d 100644
@@ -582,13 +582,16 @@ config RCU_FAST_NO_HZ
depends on NO_HZ && SMP
- This option causes RCU to attempt to accelerate grace periods in
- order to allow CPUs to enter dynticks-idle state more quickly.
- On the other hand, this option increases the overhead of the
- dynticks-idle checking, thus degrading scheduling latency.
- Say Y if energy efficiency is critically important, and you don't
- care about real-time response.
+ This option permits CPUs to enter dynticks-idle state even if
+ they have RCU callbacks queued, and prevents RCU from waking
+ these CPUs up more than roughly once every four jiffies (by
+ default, you can adjust this using the rcutree.rcu_idle_gp_delay
+ parameter), thus improving energy efficiency. On the other
+ hand, this option increases the duration of RCU grace periods,
+ for example, slowing down synchronize_rcu().
+ Say Y if energy efficiency is critically important, and you
+ don't care about increased grace-period durations.
Say N if you are unsure.