From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: RCU stall warnings...
Date: Tue, 25 Jul 2017 02:44:11 +0000 [thread overview]
Message-ID: <20170725024411.GA27413@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170724234927.GK3730@linux.vnet.ibm.com>
On Mon, Jul 24, 2017 at 04:49:27PM -0700, Paul E. McKenney wrote:
> On Mon, Jul 24, 2017 at 04:34:58PM -0700, David Miller wrote:
> > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > Date: Mon, 24 Jul 2017 16:20:33 -0700
[ . . . ]
> > That would take a while as it's hard to forcibly set this thing off.
>
> And my similar error can take awhile as well. But maybe I should try
> forcing nr_cpusC and maxcpus=8 on older versions to see what happens.
>
> A bisection would of course be quite helpful, depending of course on
> the value of "a while". ;-)
And if "a while" is too long, one alternative is to enable event tracing
for timers, as in why didn't they wake the grace-period kthread?
For example, it is possible that that kthread set its status (which
was printed out in the "rcu_sched kthread starved" message) but for
whatever reason didn't make it to the swait_event_idle_timeout()
immediately afterwards;
rsp->gp_state = RCU_GP_WAIT_FQS;
ret = swait_event_idle_timeout(rsp->gp_wq,
rcu_gp_fqs_check_wake(rsp, &gf), j);
Or that the timer-based wakeup didn't happen for whatever reason. Or...
Thanx, Paul
> > ==========
> > commit f92c734f02cbf10e40569facff82059ae9b61920
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date: Mon Apr 10 15:40:35 2017 -0700
> >
> > rcu: Prevent rcu_barrier() from starting needless grace periods
> >
> > Currently rcu_barrier() uses call_rcu() to enqueue new callbacks
> > on each CPU with a non-empty callback list. This works, but means
> > that rcu_barrier() forces grace periods that are not otherwise needed.
> > The key point is that rcu_barrier() never needs to wait for a grace
> > period, but instead only for all pre-existing callbacks to be invoked.
> > This means that rcu_barrier()'s new callbacks should be placed in
> > the callback-list segment containing the last pre-existing callback.
> >
> > This commit makes this change using the new rcu_segcblist_entrain()
> > function.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: RCU stall warnings...
Date: Mon, 24 Jul 2017 19:44:11 -0700 [thread overview]
Message-ID: <20170725024411.GA27413@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170724234927.GK3730@linux.vnet.ibm.com>
On Mon, Jul 24, 2017 at 04:49:27PM -0700, Paul E. McKenney wrote:
> On Mon, Jul 24, 2017 at 04:34:58PM -0700, David Miller wrote:
> > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > Date: Mon, 24 Jul 2017 16:20:33 -0700
[ . . . ]
> > That would take a while as it's hard to forcibly set this thing off.
>
> And my similar error can take awhile as well. But maybe I should try
> forcing nr_cpus=43 and maxcpus=8 on older versions to see what happens.
>
> A bisection would of course be quite helpful, depending of course on
> the value of "a while". ;-)
And if "a while" is too long, one alternative is to enable event tracing
for timers, as in why didn't they wake the grace-period kthread?
For example, it is possible that that kthread set its status (which
was printed out in the "rcu_sched kthread starved" message) but for
whatever reason didn't make it to the swait_event_idle_timeout()
immediately afterwards;
rsp->gp_state = RCU_GP_WAIT_FQS;
ret = swait_event_idle_timeout(rsp->gp_wq,
rcu_gp_fqs_check_wake(rsp, &gf), j);
Or that the timer-based wakeup didn't happen for whatever reason. Or...
Thanx, Paul
> > ====================
> > commit f92c734f02cbf10e40569facff82059ae9b61920
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date: Mon Apr 10 15:40:35 2017 -0700
> >
> > rcu: Prevent rcu_barrier() from starting needless grace periods
> >
> > Currently rcu_barrier() uses call_rcu() to enqueue new callbacks
> > on each CPU with a non-empty callback list. This works, but means
> > that rcu_barrier() forces grace periods that are not otherwise needed.
> > The key point is that rcu_barrier() never needs to wait for a grace
> > period, but instead only for all pre-existing callbacks to be invoked.
> > This means that rcu_barrier()'s new callbacks should be placed in
> > the callback-list segment containing the last pre-existing callback.
> >
> > This commit makes this change using the new rcu_segcblist_entrain()
> > function.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
>
next prev parent reply other threads:[~2017-07-25 2:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 22:32 RCU stall warnings David Miller
2017-07-24 22:32 ` David Miller
2017-07-24 23:20 ` Paul E. McKenney
2017-07-24 23:20 ` Paul E. McKenney
2017-07-24 23:34 ` David Miller
2017-07-24 23:34 ` David Miller
2017-07-24 23:49 ` Paul E. McKenney
2017-07-24 23:49 ` Paul E. McKenney
2017-07-25 2:44 ` Paul E. McKenney [this message]
2017-07-25 2:44 ` Paul E. McKenney
2017-07-25 3:45 ` Stephen Rothwell
2017-07-25 3:45 ` Stephen Rothwell
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=20170725024411.GA27413@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@vger.kernel.org \
/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.