All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

Commit 7db21edf authored by Paul E. McKenney's avatar Paul E. McKenney

rcu: Directly drive RCU_USER_QS from Kconfig

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: default avatarIngo Molnar <mingo@kernel.org>
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: default avatarPranith Kumar <bobby.prani@gmail.com>
Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
parent 82d0f4c0
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment