[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <280f9a31-218c-4afd-a568-28efab378580@paulmck-laptop>
Date: Thu, 18 Jan 2024 06:54:04 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Zqiang <qiang.zhang1211@...il.com>, quic_neeraju@...cinc.com,
joel@...lfernandes.org, rcu@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu/nocb: Check rdp_gp->nocb_timer in
__call_rcu_nocb_wake()
On Thu, Jan 18, 2024 at 06:51:57AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 17, 2024 at 01:07:25PM +0100, Frederic Weisbecker wrote:
> > Le Wed, Jan 17, 2024 at 06:26:16PM +0800, Zqiang a écrit :
> > > Currently, only rdp_gp->nocb_timer is used, for nocb_timer of
> > > no-rdp_gp structure, the timer_pending() is always return false,
> > > this commit therefore need to check rdp_gp->nocb_timer in
> > > __call_rcu_nocb_wake().
> > >
> > > Signed-off-by: Zqiang <qiang.zhang1211@...il.com>
> > > ---
> > > kernel/rcu/tree_nocb.h | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h
> > > index 54971afc3a9b..3f85577bddd4 100644
> > > --- a/kernel/rcu/tree_nocb.h
> > > +++ b/kernel/rcu/tree_nocb.h
> > > @@ -564,6 +564,7 @@ static void __call_rcu_nocb_wake(struct rcu_data *rdp, bool was_alldone,
> > > long lazy_len;
> > > long len;
> > > struct task_struct *t;
> > > + struct rcu_data *rdp_gp = rdp->nocb_gp_rdp;
> > >
> > > // If we are being polled or there is no kthread, just leave.
> > > t = READ_ONCE(rdp->nocb_gp_kthread);
> > > @@ -608,7 +609,7 @@ static void __call_rcu_nocb_wake(struct rcu_data *rdp, bool was_alldone,
> > > smp_mb(); /* Enqueue before timer_pending(). */
> > > if ((rdp->nocb_cb_sleep ||
> > > !rcu_segcblist_ready_cbs(&rdp->cblist)) &&
> > > - !timer_pending(&rdp->nocb_timer)) {
> > > + !timer_pending(&rdp_gp->nocb_timer)) {
> >
> > Hehe, good eyes ;-)
> >
> > I had that change in mind but while checking that area further I actually
> > wondered what is the actual purpose of this RCU_NOCB_WAKE_FORCE thing. If
> > we reach that place, it means that the nocb_gp kthread should be awaken
> > already (or the timer pending), so what does a force wake up solve in that
> > case?
> >
> > Paul, any recollection of that?
>
> Huh. We never actually do RCU_NOCB_WAKE_FORCE in v6.7, if I followed
> all the code paths correctly.
>
> Historically, I have been worried about lost wakeups. Also, there
> used to be code paths in which a wakeup was not needed, for example,
> because we knew that the ending of the current grace period would take
> care of things. Unless there was some huge pile of callbacks, in which
> case an immediate wakeup could avoid falling behind a callback flood.
>
> Given that rcutorture does test callback flooding, we appear to be OK,
> but maybe it is time to crank up the flooding more.
>
> On the other hand, I have started seeing the (very) occasional OOM
> on TREE03. (In addition to those that show up from time to time on the
> single-CPU TREE09 scenario.)
Oh, and queued for further review and testing, thank you both!
Thanx, Paul
> > In the meantime:
> >
> > Reviewed-by: Frederic Weisbecker <frederic@...nel.org>
Powered by blists - more mailing lists