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
