From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
mingo@kernel.org, jiangshanlai@gmail.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: [PATCH tip/core/rcu 12/19] rcu: Restrict RCU_STRICT_GRACE_PERIOD to at most four CPUs
Date: Tue, 11 May 2021 15:52:57 -0700 [thread overview]
Message-ID: <20210511225304.2893154-12-paulmck@kernel.org> (raw)
In-Reply-To: <20210511225241.GA2893003@paulmck-ThinkPad-P17-Gen-1>
Kernels built with CONFIG_RCU_STRICT_GRACE_PERIOD=y can experience
significant lock contention due to RCU's resulting focus on ending grace
periods as soon as possible. This is OK, but only if there are not very
many CPUs. This commit therefore puts this Kconfig option off-limits
to systems with more than four CPUs.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
kernel/rcu/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
index 1942c1f1bb65..4fd64999300f 100644
--- a/kernel/rcu/Kconfig.debug
+++ b/kernel/rcu/Kconfig.debug
@@ -116,7 +116,7 @@ config RCU_EQS_DEBUG
config RCU_STRICT_GRACE_PERIOD
bool "Provide debug RCU implementation with short grace periods"
- depends on DEBUG_KERNEL && RCU_EXPERT
+ depends on DEBUG_KERNEL && RCU_EXPERT && NR_CPUS <= 4
default n
select PREEMPT_COUNT if PREEMPT=n
help
--
2.31.1.189.g2e36527f23
next prev parent reply other threads:[~2021-05-11 22:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 22:52 [PATCH tip/core/rcu 0/19] Miscellaneous fixes for v5.14 Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 01/19] rcu: Fix typo in comment: kthead -> kthread Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 02/19] rcu: Remove the unused rcu_irq_exit_preempt() function Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 03/19] rcu: Improve tree.c comments and add code cleanups Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 04/19] rcu: Invoke rcu_spawn_core_kthreads() from rcu_spawn_gp_kthread() Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 05/19] rcu: Add ->rt_priority and ->gp_start to show_rcu_gp_kthreads() output Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 06/19] rcu: Add ->gp_max " Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 07/19] lockdep: Explicitly flag likely false-positive report Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 08/19] rcu: Reject RCU_LOCKDEP_WARN() false positives Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 09/19] rcu: Add quiescent states and boost states to show_rcu_gp_kthreads() output Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 10/19] rcu: Make RCU priority boosting work on single-CPU rcu_node structures Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 11/19] rcu: Make show_rcu_gp_kthreads() dump rcu_node structures blocking GP Paul E. McKenney
2021-05-11 22:52 ` Paul E. McKenney [this message]
2021-05-11 22:52 ` [PATCH tip/core/rcu 13/19] rcu: Make rcu_gp_cleanup() be noinline for tracing Paul E. McKenney
2021-05-11 22:52 ` [PATCH tip/core/rcu 14/19] rcu: Point to documentation of ordering guarantees Paul E. McKenney
2021-05-11 22:53 ` [PATCH tip/core/rcu 15/19] rcu: Create an unrcu_pointer() to remove __rcu from a pointer Paul E. McKenney
2021-05-11 22:53 ` [PATCH tip/core/rcu 16/19] sched/isolation: reconcile rcu_nocbs= and nohz_full= Paul E. McKenney
2021-05-11 22:53 ` [PATCH tip/core/rcu 17/19] rcu: Improve comments describing RCU read-side critical sections Paul E. McKenney
2021-05-11 22:53 ` [PATCH tip/core/rcu 18/19] rcu: Remove obsolete rcu_read_unlock() deadlock commentary Paul E. McKenney
2021-05-11 22:53 ` [PATCH tip/core/rcu 19/19] rcu: Add missing __releases() annotation Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210511225304.2893154-12-paulmck@kernel.org \
--to=paulmck@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox