All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, rcu@vger.kernel.org
Subject: Re: [PATCH 2/3] rcu/nocb: Remove NOCB deferred wakeup from rcutree_dead_cpu()
Date: Thu, 20 May 2021 02:25:53 +0200	[thread overview]
Message-ID: <20210520002553.GA22836@lothringen> (raw)
In-Reply-To: <20210519155905.GY4441@paulmck-ThinkPad-P17-Gen-1>

On Wed, May 19, 2021 at 08:59:05AM -0700, Paul E. McKenney wrote:
> On Wed, May 19, 2021 at 02:09:29AM +0200, Frederic Weisbecker wrote:
> > At CPU offline time, we make sure to flush any pending wakeup for the
> > nocb_gp kthread linked to the outgoing CPU.
> > 
> > Now we are making sure of that twice:
> > 
> > 1) From rcu_report_dead() when the outgoing CPU makes the very last
> >    local cleanups by itself before switching offline.
> > 
> > 2) From rcutree_dead_cpu(). Here the offlining CPU has gone and is truly
> >    now offline. Another CPU takes care of post-portem cleaning up and
> >    check if the offline CPU had pending wakeup.
> > 
> > Both ways are fine but we have to choose one or the other because we
> > don't need to repeat that action. Simply benefit from cache locality
> > and keep only the first solution.
> 
> But between those two calls, the CPU takes a full pass through the
> scheduler and heads into the idle loop.  What if there is a call_rcu()
> along the way, and if this was the last online CPU in its rcuog kthread's
> group of CPUs?  Wouldn't that callback be stranded until one of those
> CPUs came back online?

Nope, rcu_report_dead() is called from the idle path right before
arch_cpu_idle_dead(). There should be no call to the scheduler until the
CPU comes back online.

Thanks!

  reply	other threads:[~2021-05-20  0:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19  0:09 [PATCH 0/3] rcu/nocb cleanups Frederic Weisbecker
2021-05-19  0:09 ` [PATCH 1/3] rcu/nocb: Start moving nocb code to its own plugin file Frederic Weisbecker
2021-05-19 15:55   ` Paul E. McKenney
2021-05-20  1:02     ` Frederic Weisbecker
2021-05-20  4:54       ` Paul E. McKenney
2021-05-19  0:09 ` [PATCH 2/3] rcu/nocb: Remove NOCB deferred wakeup from rcutree_dead_cpu() Frederic Weisbecker
2021-05-19 15:59   ` Paul E. McKenney
2021-05-20  0:25     ` Frederic Weisbecker [this message]
2021-05-20  0:34       ` Paul E. McKenney
2021-05-19  0:09 ` [PATCH 3/3] rcu: Assume rcu_report_dead() always deals with local CPU Frederic Weisbecker
2021-05-19 18:51   ` Paul E. McKenney
2021-05-20  0:54     ` Frederic Weisbecker
2021-05-20  4:54       ` Paul E. McKenney

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=20210520002553.GA22836@lothringen \
    --to=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@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.