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 <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

1 files changed, 10 insertions, 7 deletions

diff --git a/init/Kconfig b/init/Kconfig
index 717584064a7e..a3a2304fa6d2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -582,13 +582,16 @@ config RCU_FAST_NO_HZ
         depends on NO_HZ && SMP
         default n
         help
-          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.