[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8ae2c077-da7c-48e8-9369-0a478acab19f@paulmck-laptop>
Date: Fri, 1 Sep 2023 07:56:11 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Joel Fernandes <joel@...lfernandes.org>,
Z qiang <qiang.zhang1211@...il.com>,
linux-kernel@...r.kernel.org, rcu@...r.kernel.org
Subject: Re: [PATCH] rcutorture: Traverse possible cpu to set maxcpu in
rcu_nocb_toggle()
On Tue, Aug 29, 2023 at 05:38:54AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 29, 2023 at 11:24:24AM +0200, Frederic Weisbecker wrote:
> > On Mon, Aug 28, 2023 at 05:51:09PM -0400, Joel Fernandes wrote:
> > > I think the issue is the loop later in the function does
> > > not try to toggle cpus that came online too late.
> > >
> > > So it does not test offloading on all CPUs just because max got updated too
> > > late.
> >
> > Right, and therefore for_each_possible_cpu() or for_each_present_cpu()
> > should be fine to iterate since it's ok to try to toggle an offline CPU.
>
> OK, so I will accept the original patch which did just that.
Which I finally did. I took the liberty of adding Frederic's Reviewed-by,
but please let me know if this is in any way inappropriate.
Thanx, Paul
> Thank you!
>
> I recently got burned by lack of workqueues on a not-yet-onlined CPU,
> hence my questions here. ;-)
>
> Thanx, Paul
>
> > > One fix could be to periodically check in the loop if a new cpu at maxcpu + 1
> > > ever got onlined. If it did, update the maxcpu.
> >
> > Is it worth the complication though?
> >
> > Thanks.
> >
> > >
> > > Thanks.
> > >
> > >
> > > >
> > > > Thanks.
Powered by blists - more mailing lists