Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1695358
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: RCU stall warnings... |
| Date | 2017-07-25 04:50 +0200 |
| Message-ID | <u6Y54-5tt-7@gated-at.bofh.it> (permalink) |
| References | <u6Ub7-2PW-1@gated-at.bofh.it> <u6UXw-3qM-11@gated-at.bofh.it> <u6V7b-3vi-13@gated-at.bofh.it> <u6VgS-3zh-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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> > >
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
RCU stall warnings... David Miller <davem@davemloft.net> - 2017-07-25 00:40 +0200
Re: RCU stall warnings... David Miller <davem@davemloft.net> - 2017-07-25 01:40 +0200
Re: RCU stall warnings... "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-25 01:50 +0200
Re: RCU stall warnings... "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-25 04:50 +0200
Re: RCU stall warnings... Stephen Rothwell <sfr@canb.auug.org.au> - 2017-07-25 05:50 +0200
csiph-web