linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Scott Wood <swood@redhat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RT 0/4] Address rcutorture issues
Date: Thu, 20 Jun 2019 12:12:59 -0700	[thread overview]
Message-ID: <20190620191259.GT26519@linux.ibm.com> (raw)
In-Reply-To: <20190619011908.25026-1-swood@redhat.com>

On Tue, Jun 18, 2019 at 08:19:04PM -0500, Scott Wood wrote:
> With these patches, rcutorture mostly works on PREEMPT_RT_FULL.  I still
> once in a while get forward progress complaints (particularly,
> rcu_torture_fwd_prog_cr) when a grace period is held up for a few seconds
> after which point so many callbacks have been enqueued that even making
> reasonable progress isn't going to beat the timeout.  I believe I've only
> seen this when running heavy loads in addition to rcutorture (though I've
> done more testing under load than without); I don't know whether the
> forward progress tests are expected to work under such load.

With current -rcu, the torture tests are ahead of RCU's forward-progress
code, so rcu_torture_fwd_prog_cr() failures are expected behavior,
particularly in the TREE04 and TREE07 scenarios.  This is more of a
problem for real-time because of callback offloading, which removes the
backpressure that normally exists from callback processing to whatever
is running on that same CPU generating so many callbacks.  So this issue
has been providing me some entertainment.  ;-)

If you put lots of load on the system while running rcutorture, but
leave the CPU running rcu_torture_fwd_prog_cr() otherwise idle, then yes,
you can eventually force rcu_torture_fwd_prog_cr() pretty much no matter
what RCU does otherwise.  Particularly given that rcutorture is running
within a guest OS.  There has been some discussion of RCU asking for help
from the hypervisor, but it hasn't yet gotten further than discussion.

For another example, if all but one of the CPUs is an no-CBs CPU
(or, equivalently, a nohz_full CPU), and all of the rcuo kthreads
are constrained to run on the remaining CPU, it is not hard to create
workloads that produce more callbacks than that remaining CPU can possibly
keep up with.  The traditional position has of course been the Spiderman
principle "With great power comes great responsibility".  ;-)

							Thanx, Paul

> Scott Wood (4):
>   rcu: Acquire RCU lock when disabling BHs
>   sched: migrate_enable: Use sleeping_lock to indicate involuntary sleep
>   rcu: unlock special: Treat irq and preempt disabled the same
>   rcutorture: Avoid problematic critical section nesting
> 
>  include/linux/rcupdate.h |  4 +++
>  include/linux/sched.h    |  4 +--
>  kernel/rcu/rcutorture.c  | 92 ++++++++++++++++++++++++++++++++++++++++--------
>  kernel/rcu/tree_plugin.h | 12 ++-----
>  kernel/rcu/update.c      |  4 +++
>  kernel/sched/core.c      |  2 ++
>  kernel/softirq.c         | 12 +++++--
>  7 files changed, 102 insertions(+), 28 deletions(-)
> 
> -- 
> 1.8.3.1
> 


      parent reply	other threads:[~2019-06-20 19:13 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19  1:19 [PATCH RT 0/4] Address rcutorture issues Scott Wood
2019-06-19  1:19 ` [PATCH RT 1/4] rcu: Acquire RCU lock when disabling BHs Scott Wood
2019-06-20 20:53   ` Paul E. McKenney
2019-06-20 21:06     ` Scott Wood
2019-06-20 21:20       ` Paul E. McKenney
2019-06-20 21:38         ` Scott Wood
2019-06-20 22:16           ` Paul E. McKenney
2019-06-19  1:19 ` [PATCH RT 2/4] sched: migrate_enable: Use sleeping_lock to indicate involuntary sleep Scott Wood
2019-06-19  1:19 ` [RFC PATCH RT 3/4] rcu: unlock special: Treat irq and preempt disabled the same Scott Wood
2019-06-20 21:10   ` Paul E. McKenney
2019-06-20 21:59     ` Scott Wood
2019-06-20 22:25       ` Paul E. McKenney
2019-06-20 23:08         ` Scott Wood
2019-06-22  0:26           ` Paul E. McKenney
2019-06-22 19:13             ` Paul E. McKenney
2019-06-24 17:40               ` Scott Wood
2019-06-19  1:19 ` [RFC PATCH RT 4/4] rcutorture: Avoid problematic critical section nesting Scott Wood
2019-06-20 21:18   ` Paul E. McKenney
2019-06-20 21:43     ` Scott Wood
2019-06-21 16:38     ` Sebastian Andrzej Siewior
2019-06-21 23:59       ` Paul E. McKenney
2019-06-26 15:08         ` Steven Rostedt
2019-06-26 16:49           ` Scott Wood
2019-06-27 18:00             ` Paul E. McKenney
2019-06-27 20:16               ` Scott Wood
2019-06-27 20:50                 ` Paul E. McKenney
2019-06-27 22:46                   ` Scott Wood
2019-06-28  0:52                     ` Paul E. McKenney
2019-06-28 19:37                       ` Scott Wood
2019-06-28 20:24                         ` Paul E. McKenney
2019-06-20 19:12 ` Paul E. McKenney [this message]

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=20190620191259.GT26519@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=swood@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /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).