Merge branch 'rcu/next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu

Pull the v3.5 RCU tree from Paul E. McKenney:

 1)	A set of improvements and fixes to the RCU_FAST_NO_HZ feature
	(with more on the way for 3.6).  Posted to LKML:
	https://lkml.org/lkml/2012/4/23/324 (commits 1-3 and 5),
	https://lkml.org/lkml/2012/4/16/611 (commit 4),
	https://lkml.org/lkml/2012/4/30/390 (commit 6), and
	https://lkml.org/lkml/2012/5/4/410 (commit 7, combined with
	the other commits for the convenience of the tester).

 2)	Changes to make rcu_barrier() avoid disrupting execution of CPUs
	that have no RCU callbacks.  Posted to LKML:
	https://lkml.org/lkml/2012/4/23/322.

 3)	A couple of commits that improve the efficiency of the interaction
	between preemptible RCU and the scheduler, these two being all
	that survived an abortive attempt to allow preemptible RCU's
	__rcu_read_lock() to be inlined.  The full set was posted to
	LKML at https://lkml.org/lkml/2012/4/14/143, and the first and
	third patches of that set remain.

 4)	Lai Jiangshan's algorithmic implementation of SRCU, which includes
	call_srcu() and srcu_barrier().  A major feature of this new
	implementation is that synchronize_srcu() no longer disturbs
	the execution of other CPUs.  This work is based on earlier
	implementations by Peter Zijlstra and Paul E. McKenney.  Posted to
	LKML: https://lkml.org/lkml/2012/2/22/82.

 5)	A number of miscellaneous bug fixes and improvements which were
	posted to LKML at: https://lkml.org/lkml/2012/4/23/353 with
	subsequent updates posted to LKML.

Signed-off-by: Ingo Molnar <mingo@kernel.org>

1 files changed, 46 insertions, 4 deletions

diff --git a/init/Kconfig b/init/Kconfig
index 6cfd71d06463..6d18ef8071b5 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -458,6 +458,33 @@ config RCU_FANOUT
           Select a specific number if testing RCU itself.
           Take the default if unsure.
 
+config RCU_FANOUT_LEAF
+        int "Tree-based hierarchical RCU leaf-level fanout value"
+        range 2 RCU_FANOUT if 64BIT
+        range 2 RCU_FANOUT if !64BIT
+        depends on TREE_RCU || TREE_PREEMPT_RCU
+        default 16
+        help
+          This option controls the leaf-level fanout of hierarchical
+          implementations of RCU, and allows trading off cache misses
+          against lock contention.  Systems that synchronize their
+          scheduling-clock interrupts for energy-efficiency reasons will
+          want the default because the smaller leaf-level fanout keeps
+          lock contention levels acceptably low.  Very large systems
+          (hundreds or thousands of CPUs) will instead want to set this
+          value to the maximum value possible in order to reduce the
+          number of cache misses incurred during RCU's grace-period
+          initialization.  These systems tend to run CPU-bound, and thus
+          are not helped by synchronized interrupts, and thus tend to
+          skew them, which reduces lock contention enough that large
+          leaf-level fanouts work well.
+
+          Select a specific number if testing RCU itself.
+
+          Select the maximum permissible value for large systems.
+
+          Take the default if unsure.
+
 config RCU_FANOUT_EXACT
         bool "Disable tree-based hierarchical RCU auto-balancing"
         depends on TREE_RCU || TREE_PREEMPT_RCU
@@ -515,10 +542,25 @@ config RCU_BOOST_PRIO
         depends on RCU_BOOST
         default 1
         help
-          This option specifies the real-time priority to which preempted
-          RCU readers are to be boosted.  If you are working with CPU-bound
-          real-time applications, you should specify a priority higher then
-          the highest-priority CPU-bound application.
+          This option specifies the real-time priority to which long-term
+          preempted RCU readers are to be boosted.  If you are working
+          with a real-time application that has one or more CPU-bound
+          threads running at a real-time priority level, you should set
+          RCU_BOOST_PRIO to a priority higher then the highest-priority
+          real-time CPU-bound thread.  The default RCU_BOOST_PRIO value
+          of 1 is appropriate in the common case, which is real-time
+          applications that do not have any CPU-bound threads.
+
+          Some real-time applications might not have a single real-time
+          thread that saturates a given CPU, but instead might have
+          multiple real-time threads that, taken together, fully utilize
+          that CPU.  In this case, you should set RCU_BOOST_PRIO to
+          a priority higher than the lowest-priority thread that is
+          conspiring to prevent the CPU from running any non-real-time
+          tasks.  For example, if one thread at priority 10 and another
+          thread at priority 5 are between themselves fully consuming
+          the CPU time on a given CPU, then RCU_BOOST_PRIO should be
+          set to priority 6 or higher.
 
           Specify the real-time priority, or take the default if unsure.