linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.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@linux.ibm.com>
Subject: [PATCH tip/core/rcu 01/12] rcu: Accommodate zero jiffies_till_first_fqs and kthread kicking
Date: Wed,  9 Jan 2019 13:28:23 -0800	[thread overview]
Message-ID: <20190109212834.1257-1-paulmck@linux.ibm.com> (raw)
In-Reply-To: <20190109212816.GA32282@linux.ibm.com>

It is perfectly fine to set the rcutree.jiffies_till_first_fqs boot
parameter to zero, in fact, this can be useful on specialty systems that
usually have at least one idle CPU and that need fast grace periods.
This is because this setting causes the RCU grace-period kthread to
scan for idle threads immediately after grace-period initialization,
as opposed to waiting several jiffies to do so.

It is also perfectly fine to set the rcutree.rcu_kick_kthreads kernel
parameter, which gives the RCU grace-period kthread an extra wakeup
if it doesn't make progress for a period of three times the setting of
the rcutree.jiffies_till_first_fqs boot parameter.  This is of course
problematic when the value of this parameter is zero, as it can result
in unnecessary wakeup IPIs along with unnecessary WARN_ONCE() invocations.

This commit therefore defers kthread kicking for at least two jiffies,
regardless of the setting of rcutree.jiffies_till_first_fqs.

Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
---
 kernel/rcu/tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 9180158756d2..b003a3cfe192 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1939,7 +1939,7 @@ static void rcu_gp_fqs_loop(void)
 		if (!ret) {
 			rcu_state.jiffies_force_qs = jiffies + j;
 			WRITE_ONCE(rcu_state.jiffies_kick_kthreads,
-				   jiffies + 3 * j);
+				   jiffies + (j ? 3 * j : 2));
 		}
 		trace_rcu_grace_period(rcu_state.name,
 				       READ_ONCE(rcu_state.gp_seq),
-- 
2.17.1


  reply	other threads:[~2019-01-09 21:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 21:28 [PATCH tip/core/rcu 0/12] Forward-progress changes for v5.1 Paul E. McKenney
2019-01-09 21:28 ` Paul E. McKenney [this message]
2019-01-09 21:28 ` [PATCH tip/core/rcu 02/12] rcu: Move rcu_cpu_kthread_task to rcu_data structure Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 03/12] rcu: Move rcu_cpu_kthread_status " Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 04/12] rcu: Remove unused rcu_cpu_kthread_loops per-CPU variable Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 05/12] rcu: Move rcu_cpu_has_work to rcu_data structure Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 06/12] rcu: Remove unused rcu_cpu_kthread_cpu per-CPU variable Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 07/12] rcu: Update NOCB comments Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 08/12] rcu: Improve diagnostics for failed RCU grace-period start Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 09/12] rcu: Protect rcu_check_gp_kthread_starvation() access to ->gp_flags Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 10/12] rcu: Add sysrq rcu_node-dump capability Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 11/12] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt Paul E. McKenney
2019-01-09 21:28 ` [PATCH tip/core/rcu 12/12] rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes() 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=20190109212834.1257-1-paulmck@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).