[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211213212108.GA786870@lothringen>
Date: Mon, 13 Dec 2021 22:21:08 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: "Woodhouse, David" <dwmw@...zon.co.uk>,
"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
"quic_neeraju@...cinc.com" <quic_neeraju@...cinc.com>,
"jiangshanlai@...il.com" <jiangshanlai@...il.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"josh@...htriplett.org" <josh@...htriplett.org>,
"joel@...lfernandes.org" <joel@...lfernandes.org>,
"urezki@...il.com" <urezki@...il.com>,
"rcu@...r.kernel.org" <rcu@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"boqun.feng@...il.com" <boqun.feng@...il.com>
Subject: Re: [PATCH] rcu: Make rcu_state.n_online_cpus updates atomic
On Mon, Dec 13, 2021 at 11:32:56AM -0800, Paul E. McKenney wrote:
> On Mon, Dec 13, 2021 at 08:09:22AM +0000, Woodhouse, David wrote:
> > On Mon, 2021-12-13 at 12:30 +0530, Neeraj Upadhyay wrote:
> > > To support onlining multiple CPUs concurrently,
> > > change rcu_state.n_online_cpus updates to be atomic.
> > > Note, it's ok for rcu_blocking_is_gp() to do a
> > > atomic_read(&rcu_state.n_online_cpus), as the
> > > value of .n_online_cpus switches from 1->2, in
> > > rcutree_prepare_cpu(), which runs before the new
> > > CPU comes online. Similarly 2->1 transition happens
> > > from rcutree_dead_cpu(), which executes after the
> > > CPU is offlined, and runs on the last online CPU.
> > >
> > > Signed-off-by: Neeraj Upadhyay <quic_neeraju@...cinc.com>
> >
> > In my parallel-bringup series, the prepare stages are still being
> > executed in series on the BSP, so I don't think this patch is needed
> > yet. I'm not sure we'd ever end up with the prepare stages being done
> > in parallel — the most I see us doing is onlining a single *batch* of
> > CPUs at a time, much like bringup_nonboot_cpus() does.
> >
> > But this patch certainly doesn't *hurt*.
> >
> > Acked-by: David Woodhouse <dwmw@...zon.co.uk>
>
> Queued for further review and testing.
>
> To Frederic's point, this won't go to mainline unless it is actually
> needed, but it will at least be pulled into a branch in -rcu marked with
> a tag for future reference.
Ok, sounds reasonable then.
Thanks!
Powered by blists - more mailing lists