[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170123202559.GA1007@cloud>
Date: Mon, 23 Jan 2017 12:25:59 -0800
From: Josh Triplett <josh@...htriplett.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH v2 tip/core/rcu 07/18] rcu: Add long-term CPU kicking
On Mon, Jan 23, 2017 at 11:34:45AM -0800, Paul E. McKenney wrote:
> On Sat, Jan 21, 2017 at 12:42:55PM -0800, Josh Triplett wrote:
> > On Tue, Jan 17, 2017 at 06:53:46PM -0800, Paul E. McKenney wrote:
> > > Commit d2db185bfee8 ("rcu: Remove short-term CPU kicking") removed
> > > frequent calls to resched_cpu(), which means that the only time
> > > resched_cpu() is invoked is after an RCU CPU stall warning. Although
> > > this is good from an avoid-IPIs perspective, we should try to break
> > > things loose -before- splatting. This commit therefore starts invoking
> > > resched_cpu() for each holdout at each force-quiescent-state interval
> > > that is more than halfway through the stall-warning interval.
> >
> > Just realized an issue with this commit message: you're referring to
> > what now appears as patch 8 in the past tense as something already done,
> > and with a commit ID that probably doesn't work anymore. You need to
> > rephrase this to describe how it leads to a *subsequent* change rather
> > than fixing something already changed.
> >
> > With the commit message fixed:
> > Reviewed-by: Josh Triplett <josh@...htriplett.org>
>
> Good point! It now reads as follows:
>
> ------------------------------------------------------------------------
> This commit prepares for the removal of short-term CPU kicking (in a
> subsequent commit). It does so by starting to invoke resched_cpu()
> for each holdout at each force-quiescent-state interval that is more
> than halfway through the stall-warning interval.
> ------------------------------------------------------------------------
>
> Does that work?
Looks good to me.
> Thanx, Paul
>
> > > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> >
> >
> >
> > > ---
> > > kernel/rcu/tree.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 83bf054e194e..0e61b62e3f4a 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -1225,6 +1225,12 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
> > > rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
> > > ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
> > > resched_cpu(rdp->cpu); /* Force CPU into scheduler. */
> > > + /*
> > > + * If more than halfway to RCU CPU stall-warning time, do
> > > + * a resched_cpu() to try to loosen things up a bit.
> > > + */
> > > + if (jiffies - rdp->rsp->gp_start > rcu_jiffies_till_stall_check() / 2)
> > > + resched_cpu(rdp->cpu);
> > >
> > > return 0;
> > > }
> > > --
> > > 2.5.2
> > >
> >
>
Powered by blists - more mailing lists