lkml.org 
[lkml]   [2023]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/4] rcu/nocb: Protect lazy shrinker against concurrent (de-)offloading
On Wed, Mar 29, 2023 at 06:07:58PM +0200, Frederic Weisbecker wrote:
> On Sun, Mar 26, 2023 at 02:45:18PM -0700, Paul E. McKenney wrote:
> > On Sun, Mar 26, 2023 at 10:01:34PM +0200, Frederic Weisbecker wrote:
> > > > > > > /* Snapshot count of all CPUs */
> > > > > > > for_each_possible_cpu(cpu) {
> > > > > > > struct rcu_data *rdp = per_cpu_ptr(&rcu_data, cpu);
> > > > > > > - int _count = READ_ONCE(rdp->lazy_len);
> > > > > > > + int _count;
> > > > > > > +
> > > > > > > + if (!rcu_rdp_is_offloaded(rdp))
> > > > > > > + continue;
> > > > > >
> > > > > > If the CPU is offloaded, isn't ->lazy_len guaranteed to be zero?
> > > > > >
> > > > > > Or can it contain garbage after a de-offloading operation?
> > > > >
> > > > > If it's deoffloaded, ->lazy_len is indeed (supposed to be) guaranteed to be zero.
> > > > > Bypass is flushed and disabled atomically early on de-offloading and the
> > > > > flush resets ->lazy_len.
> > > >
> > > > Whew! At the moment, I don't feel strongly about whether or not
> > > > the following code should (1) read the value, (2) warn on non-zero,
> > > > (3) assume zero without reading, or (4) some other option that is not
> > > > occurring to me. Your choice!
> > >
> > > (2) looks like a good idea!
> >
> > Sounds good to me!
>
> So since we now iterate rcu_nocb_mask after the patchset, there is no more
> deoffloaded rdp to check. Meanwhile I put a WARN in the new series making
> sure that an rdp in rcu_nocb_mask is also offloaded (heh!)

Sounds good, thank you!

Thanx, Paul

\
 
 \ /
  Last update: 2023-03-29 22:46    [W:0.048 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site