[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ca81dd6-af72-4345-9689-a1ef7dadfa95@paulmck-laptop>
Date: Tue, 29 Aug 2023 05:38:54 -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 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.
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