Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

rcu: Directly drive RCU_USER_QS from Kconfig

Browse source 
Currently, Kconfig will ask the user whether RCU_USER_QS should be set.
This is silly because Kconfig already has all the information that it
needs to set this parameter.  This commit therefore directly drives
the value of RCU_USER_QS via NO_HZ_FULL's "select" statement.

Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
This commit is contained in:
Paul E. McKenney 2015-04-20 06:17:15 -07:00
parent 82d0f4c089
commit 7db21edfec
1 changed files with 1 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
init/Kconfig
View file

@ -529,9 +529,7 @@ config CONTEXT_TRACKING
bool
config RCU_USER_QS
bool "Consider userspace as in RCU extended quiescent state"
depends on HAVE_CONTEXT_TRACKING && SMP
select CONTEXT_TRACKING
bool
help
This option sets hooks on kernel / userspace boundaries and
puts RCU in extended quiescent state when the CPU runs in
@ -539,12 +537,6 @@ config RCU_USER_QS
excluded from the global RCU state machine and thus doesn't
try to keep the timer tick on for RCU.
Unless you want to hack and help the development of the full
dynticks mode, you shouldn't enable this option. It also
adds unnecessary overhead.
If unsure say N
config CONTEXT_TRACKING_FORCE
bool "Force context tracking"
depends on CONTEXT_TRACKING