Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

* 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (64 commits)
  cpu: Export cpu_up()
  rcu: Apply ACCESS_ONCE() to rcu_boost() return value
  Revert "rcu: Permit rt_mutex_unlock() with irqs disabled"
  docs: Additional LWN links to RCU API
  rcu: Augment rcu_batch_end tracing for idle and callback state
  rcu: Add rcutorture tests for srcu_read_lock_raw()
  rcu: Make rcutorture test for hotpluggability before offlining CPUs
  driver-core/cpu: Expose hotpluggability to the rest of the kernel
  rcu: Remove redundant rcu_cpu_stall_suppress declaration
  rcu: Adaptive dyntick-idle preparation
  rcu: Keep invoking callbacks if CPU otherwise idle
  rcu: Irq nesting is always 0 on rcu_enter_idle_common
  rcu: Don't check irq nesting from rcu idle entry/exit
  rcu: Permit dyntick-idle with callbacks pending
  rcu: Document same-context read-side constraints
  rcu: Identify dyntick-idle CPUs on first force_quiescent_state() pass
  rcu: Remove dynticks false positives and RCU failures
  rcu: Reduce latency of rcu_prepare_for_idle()
  rcu: Eliminate RCU_FAST_NO_HZ grace-period hang
  rcu: Avoid needlessly IPIing CPUs at GP end
  ...

1 files changed, 5 insertions, 5 deletions

diff --git a/init/Kconfig b/init/Kconfig
index 43298f9810fb..82b6a4c675b2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -469,14 +469,14 @@ config RCU_FANOUT_EXACT
 
 config RCU_FAST_NO_HZ
         bool "Accelerate last non-dyntick-idle CPU's grace periods"
-        depends on TREE_RCU && NO_HZ && SMP
+        depends on NO_HZ && SMP
         default n
         help
           This option causes RCU to attempt to accelerate grace periods
-          in order to allow the final CPU to enter dynticks-idle state
-          more quickly.  On the other hand, this option increases the
-          overhead of the dynticks-idle checking, particularly on systems
-          with large numbers of CPUs.
+          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, particularly on systems with
+          large numbers of CPUs.
 
           Say Y if energy efficiency is critically important, particularly
                 if you have relatively few CPUs.