Re: [PATCH 1/1] mm/thp: clear deferred split shrinker bits when queues drain

[Lance Yang]

On 2026/6/2 20:11, David Hildenbrand (Arm) wrote:
> On 6/2/26 06:38, Lance Yang wrote:
> > Sorry, I missed Johannes in Cc ...
> >
> > On 2026/6/2 12:34, Lance Yang wrote:
> > > From: Lance Yang <lance.yang@xxxxxxxxx>
> > >
> > > deferred_split_count() returns the raw list_lru count. When the per-memcg,
> > > per-node list is empty, that count is 0.
> > >
> > > That skips scanning, but it does not tell memcg reclaim that the shrinker
> > > is empty. shrink_slab_memcg() only clears the memcg shrinker bit when the
> > > count callback reports SHRINK_EMPTY.
>
> What's the effect of that? Would we consider it a fix that we'd want to backport?

Just a stale memcg shrinker bit :) I'd treat this patch as a small
cleanup.

Once the queue is empty, count_objects() returns 0. That skips the scan,
but shrink_slab_memcg() only clears the bit on SHRINK_EMPTY, not 0.

So memcg reclaim can keep calling the shrinker even though there is
nothing on that queue.

> > > Return SHRINK_EMPTY for an empty deferred split list, so the bit can be
> > > cleared once the queue has drained.
> > >
> > > Signed-off-by: Lance Yang <lance.yang@xxxxxxxxx>
> > > ---
> > >    mm/huge_memory.c | 5 ++++-
> > >    1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index 72f6caf0fec6..62d598290c3b 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -4397,7 +4397,10 @@ void deferred_split_folio(struct folio *folio, bool
> > > partially_mapped)
> > >    static unsigned long deferred_split_count(struct shrinker *shrink,
> > >            struct shrink_control *sc)
> > >    {
> > > -    return list_lru_shrink_count(&deferred_split_lru, sc);
> > > +    unsigned long count;
> > > +
> > > +    count = list_lru_shrink_count(&deferred_split_lru, sc);
> > > +    return count ?: SHRINK_EMPTY;
> > >    }
> > >      static bool thp_underused(struct folio *folio)
>
> This is against Johannes' work, right?

Yep, I noticed it there, but the behavior is older.

> If this is a fix, likely it would be fixing 87eaceb3faa5 ("mm: thp: make
> deferred split shrinker memcg aware"), right?

No missed reclaim, just some extra reclaim work :)

Cheers, Lance