All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	tglx@linutronix.de, Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH v3] rcu: Allow to eliminate softirq processing from rcutree
Date: Mon, 25 Mar 2019 08:52:20 -0700	[thread overview]
Message-ID: <20190325155219.GA7312@linux.ibm.com> (raw)
In-Reply-To: <20190325150800.GB4102@linux.ibm.com>

On Mon, Mar 25, 2019 at 08:08:00AM -0700, Paul E. McKenney wrote:
> On Mon, Mar 25, 2019 at 09:41:29AM -0400, Joel Fernandes wrote:
> > On Sun, Mar 24, 2019 at 04:42:11PM -0700, Paul E. McKenney wrote:
> > > On Sat, Mar 23, 2019 at 09:10:02AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Mar 22, 2019 at 05:25:19PM -0700, Paul E. McKenney wrote:
> > > > > On Fri, Mar 22, 2019 at 07:48:19PM -0400, Joel Fernandes wrote:
> > > > > > On Wed, Mar 20, 2019 at 10:13:33PM +0100, Sebastian Andrzej Siewior wrote:
> > > > > > > Running RCU out of softirq is a problem for some workloads that would
> > > > > > > like to manage RCU core processing independently of other softirq
> > > > > > > work, for example, setting kthread priority.  This commit therefore
> > > > > > > introduces the `rcunosoftirq' option which moves the RCU core work
> > > > > > > from softirq to a per-CPU/per-flavor SCHED_OTHER kthread named rcuc.
> > > > > > > The SCHED_OTHER approach avoids the scalability problems that appeared
> > > > > > > with the earlier attempt to move RCU core processing to from softirq
> > > > > > > to kthreads.  That said, kernels built with RCU_BOOST=y will run the
> > > > > > > rcuc kthreads at the RCU-boosting priority.
> > > > > > [snip]
> > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > > > index 0f31b79eb6761..05a1e42fdaf10 100644
> > > > > > > --- a/kernel/rcu/tree.c
> > > > > > > +++ b/kernel/rcu/tree.c
> > > > > > > @@ -51,6 +51,12 @@
> > > > > > >  #include <linux/tick.h>
> > > > > > >  #include <linux/sysrq.h>
> > > > > > >  #include <linux/kprobes.h>
> > > > > > > +#include <linux/gfp.h>
> > > > > > > +#include <linux/oom.h>
> > > > > > > +#include <linux/smpboot.h>
> > > > > > > +#include <linux/jiffies.h>
> > > > > > > +#include <linux/sched/isolation.h>
> > > > > > > +#include "../time/tick-internal.h"
> > > > > > >  
> > > > > > >  #include "tree.h"
> > > > > > >  #include "rcu.h"
> > > > > > > @@ -92,6 +98,9 @@ struct rcu_state rcu_state = {
> > > > > > >  /* Dump rcu_node combining tree at boot to verify correct setup. */
> > > > > > >  static bool dump_tree;
> > > > > > >  module_param(dump_tree, bool, 0444);
> > > > > > > +/* Move RCU_SOFTIRQ to rcuc kthreads. */
> > > > > > > +static bool use_softirq = 1;
> > > > > > > +module_param(use_softirq, bool, 0444);
> > > > > > >  /* Control rcu_node-tree auto-balancing at boot time. */
> > > > > > >  static bool rcu_fanout_exact;
> > > > > > >  module_param(rcu_fanout_exact, bool, 0444);
> > > > > > > @@ -2253,7 +2262,7 @@ void rcu_force_quiescent_state(void)
> > > > > > >  EXPORT_SYMBOL_GPL(rcu_force_quiescent_state);
> > > > > > >  
> > > > > > >  /* Perform RCU core processing work for the current CPU.  */
> > > > > > > -static __latent_entropy void rcu_core(struct softirq_action *unused)
> > > > > > > +static __latent_entropy void rcu_core(void)
> > > > > > >  {
> > > > > > >  	unsigned long flags;
> > > > > > >  	struct rcu_data *rdp = raw_cpu_ptr(&rcu_data);
> > > > > > > @@ -2295,6 +2304,34 @@ static __latent_entropy void rcu_core(struct softirq_action *unused)
> > > > > > >  	trace_rcu_utilization(TPS("End RCU core"));
> > > > > > >  }
> > > > > > >  
> > > > > > > +static void rcu_core_si(struct softirq_action *h)
> > > > > > > +{
> > > > > > > +	rcu_core();
> > > > > > > +}
> > > > > > > +
> > > > > > > +static void rcu_wake_cond(struct task_struct *t, int status)
> > > > > > > +{
> > > > > > > +	/*
> > > > > > > +	 * If the thread is yielding, only wake it when this
> > > > > > > +	 * is invoked from idle
> > > > > > > +	 */
> > > > > > > +	if (t && (status != RCU_KTHREAD_YIELDING || is_idle_task(current)))
> > > > > > > +		wake_up_process(t);
> > > > > > > +}
> > > > > > > +
> > > > > > > +static void invoke_rcu_core_kthread(void)
> > > > > > > +{
> > > > > > > +	struct task_struct *t;
> > > > > > > +	unsigned long flags;
> > > > > > > +
> > > > > > > +	local_irq_save(flags);
> > > > > > > +	__this_cpu_write(rcu_data.rcu_cpu_has_work, 1);
> > > > > > > +	t = __this_cpu_read(rcu_data.rcu_cpu_kthread_task);
> > > > > > > +	if (t != NULL && t != current)
> > > > > > > +		rcu_wake_cond(t, __this_cpu_read(rcu_data.rcu_cpu_kthread_status));
> > > > > > > +	local_irq_restore(flags);
> > > > > > > +}
> > > > > > > +
> > > > > > >  /*
> > > > > > >   * Schedule RCU callback invocation.  If the running implementation of RCU
> > > > > > >   * does not support RCU priority boosting, just do a direct call, otherwise
> > > > > > > @@ -2306,19 +2343,95 @@ static void invoke_rcu_callbacks(struct rcu_data *rdp)
> > > > > > >  {
> > > > > > >  	if (unlikely(!READ_ONCE(rcu_scheduler_fully_active)))
> > > > > > >  		return;
> > > > > > > -	if (likely(!rcu_state.boost)) {
> > > > > > > -		rcu_do_batch(rdp);
> > > > > > > -		return;
> > > > > > > -	}
> > > > > > > -	invoke_rcu_callbacks_kthread();
> > > > > > > +	if (rcu_state.boost || !use_softirq)
> > > > > > > +		invoke_rcu_core_kthread();
> > > > > > > +	rcu_do_batch(rdp);
> > > > > > 
> > > > > > Shouldn't there be an else before the rcu_do_batch? If we are waking up the
> > > > > > rcuc thread, then that will do the rcu_do_batch when it runs right?
> > > > > > 
> > > > > > Something like:
> > > > > > 	if (rcu_state.boost || !use_softirq)
> > > > > > 		invoke_rcu_core_kthread();
> > > > > > 	else
> > > > > > 		rcu_do_batch(rdp);
> > > > > > 
> > > > > > Previous code similarly had a return; also.
> > > > > 
> > > > > I believe that you are correct, so I will give it a shot.  Good eyes!
> > > > 
> > > > Yet rcutorture disagrees.  Actually, if we are using rcuc kthreads, this
> > > > is only ever invoked from within tha thread, so the only check we need is
> > > > for the scheduler being operational.  I am therefore trying this one out.
> > > > 
> > > > Thoughts?
> > > 
> > > And rcutorture likes this one, though at this point this function should
> > > be pulled into its sole callsite.  ;-)
> > 
> > Great, I'm glad the testing is going well.
> 
> Which reminds me...  I have been assuming that Frederic Weisbecker's
> split-softirq patches were stalled for the time being.
> 
> http://lkml.kernel.org/r/20190228171242.32144-1-frederic@kernel.org
> 
> If those were to show up soonish, perhaps that would allow per-softirq
> control of priority.
> 
> My thought is not to wait, but I figured I should mention it.
> 
> > By the way I enlightened that jitter.sh script about CPU offline issues as
> > well (sent patch last week).  Let me know if you agree with it.
> 
> I just sent a reply.  Still trying to remember why I excluded CPU 0.  ;-)
> 
> Perhaps because of issues with single-CPU rcutorture runs?

I also considered and rejected the following patch because it actually
can make sense to build with CONFIG_RCU_BOOST but still use softirq, for
example, when SCHED_IDLE tasks might get stuck in RCU read-side critical
sections.  But then I noticed that rcu_spawn_core_kthreads() unconditionally
creates the rcuc kthreads if CONFIG_RCU_BOOST.

So I either need to apply the patch below, or I need to remove
the "!IS_ENABLED(CONFIG_RCU_BOOST)" from the "if" statement in
rcu_spawn_core_kthreads().  The question is "do we allow CONFIG_RCU_BOOST
kernels to use RCU_SOFTIRQ?"  Some plusses and minuses:

+	Supports the SCHED_IDLE use case for CONFIG_RCU_BOOST without
	slowing down other workloads.  This might be important given
	RCU flavor consolidation

-	Another configuration combination to test and maintain.

So I am leaning towards ditching the patch below in favor of updating
the "if" condition in rcu_spawn_core_kthreads().

Thoughts?

							Thanx, Paul

------------------------------------------------------------------------

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a17034ee4d3d..5782fe9ac27d 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -99,8 +99,12 @@ struct rcu_state rcu_state = {
 static bool dump_tree;
 module_param(dump_tree, bool, 0444);
 /* By default, use RCU_SOFTIRQ instead of rcuc kthreads. */
+#ifdef CONFIG_RCU_BOOST
+static const bool use_softirq = 0;
+#else /* #ifdef CONFIG_RCU_BOOST */
 static bool use_softirq = 1;
 module_param(use_softirq, bool, 0444);
+#endif /* #else #ifdef CONFIG_RCU_BOOST */
 /* Control rcu_node-tree auto-balancing at boot time. */
 static bool rcu_fanout_exact;
 module_param(rcu_fanout_exact, bool, 0444);


  reply	other threads:[~2019-03-25 15:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 11:11 [PATCH] rcu: Allow to eliminate softirq processing from rcutree Sebastian Andrzej Siewior
2019-03-15 13:35 ` Steven Rostedt
2019-03-15 13:57   ` Sebastian Andrzej Siewior
2019-03-18  2:24 ` Paul E. McKenney
2019-03-19 11:44   ` [PATCH v2] " Sebastian Andrzej Siewior
2019-03-19 15:59     ` Paul E. McKenney
2019-03-19 16:24       ` Sebastian Andrzej Siewior
2019-03-19 16:50         ` Paul E. McKenney
2019-03-19 17:02           ` Sebastian Andrzej Siewior
2019-03-20 11:32     ` Sebastian Andrzej Siewior
2019-03-20 15:21       ` Paul E. McKenney
2019-03-20 15:44         ` Paul E. McKenney
2019-03-20 16:05           ` Sebastian Andrzej Siewior
2019-03-20 16:15             ` Paul E. McKenney
2019-03-20 16:35               ` Sebastian Andrzej Siewior
2019-03-20 17:30                 ` Paul E. McKenney
2019-03-20 17:59                   ` Sebastian Andrzej Siewior
2019-03-20 18:12                     ` Paul E. McKenney
2019-03-20 18:14                       ` Sebastian Andrzej Siewior
2019-03-20 21:13                         ` [PATCH v3] " Sebastian Andrzej Siewior
2019-03-20 23:46                           ` Paul E. McKenney
2019-03-21  8:27                             ` Sebastian Andrzej Siewior
2019-03-21 13:26                               ` Paul E. McKenney
2019-03-21 23:32                             ` Paul E. McKenney
2019-03-22  7:35                               ` Paul E. McKenney
2019-03-22 12:43                                 ` Paul E. McKenney
2019-03-22 13:42                               ` Joel Fernandes
2019-03-22 14:58                                 ` Paul E. McKenney
2019-03-22 15:50                                   ` Joel Fernandes
2019-03-22 16:26                                     ` Paul E. McKenney
2019-03-22 18:07                                       ` Paul E. McKenney
2019-03-22 23:48                           ` Joel Fernandes
2019-03-23  0:25                             ` Paul E. McKenney
2019-03-23  1:04                               ` Joel Fernandes
2019-03-23 16:10                               ` Paul E. McKenney
2019-03-24 23:42                                 ` Paul E. McKenney
2019-03-25 13:41                                   ` Joel Fernandes
2019-03-25 15:08                                     ` Paul E. McKenney
2019-03-25 15:52                                       ` Paul E. McKenney [this message]
2019-03-20  0:26 ` [PATCH] " Joel Fernandes
2019-03-20 11:28   ` Sebastian Andrzej Siewior
2019-03-21 12:06     ` Joel Fernandes
2019-03-21 13:52       ` Paul E. McKenney
2019-03-20 15:24   ` 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=20190325155219.GA7312@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=efault@gmx.de \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.