Re: [PATCH v6 42/45] mm: shrinker: make global slab shrink lockless

[Dave Chinner]

On Wed, Dec 06, 2023 at 04:23:24PM +0800, Lai Jiangshan wrote:
> On Wed, Dec 6, 2023 at 3:55 PM Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> wrote:
> > On 2023/12/6 15:47, Lai Jiangshan wrote:
> > > On Tue, Sep 12, 2023 at 9:57 PM Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> wrote:
> > >
> > No, this_shrinker will not be removed from the shrinker_list until the
> > last refcount is released. See below:
> >
> > > rcu_read_lock();
> > > shrinker_put(this_shrinker);
> >
> >         CPU 1                                      CPU 2
> >
> >    --> if (refcount_dec_and_test(&shrinker->refcount))
> >                 complete(&shrinker->done);
> >
> >                                 wait_for_completion(&shrinker->done);
> >                                  list_del_rcu(&shrinker->list);
> 
> since shrinker will not be removed from the shrinker_list until the
> last refcount is released.
> 
> Is it possible that shrinker_free() can be starved by continuous
> scanners getting and putting the refcount?

In theory, yes. In practice, highly improbable. i.e. I don't think
this will ever be an issue because the timing conditions for memory
reclaim to keep a permanently elevated reference count on a shrinker
for a subsystem that is being torn down are -highly- improbable.

And even if you could pull it off, who cares if shrinker_free() is
delayed? It's a teardown operation meaning the subsystem using the
shrinker will no longer be in use so the latency of the teardown
operation is largely irrelevant to whatever is still running
on the system.

-Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx