Re: [PATCH v3] mm: unqueue deferred split folios outside the lruvec lock

[Barry Song]

On Wed, Oct 21, 2026 at 6:36 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 19 Oct 2026 16:06:46 -0700 Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
>
> > move_folios_to_lru(), folio_batch_move_lru() and folios_put_refs() call
> > folio_unqueue_deferred_split() on folios where the refcount has dropped
> > to zero. In these paths, folio_unqueue_deferred_split() is called with
> > the lruvec lock often held (move_folios_to_lru() always holds it and
> > folio_batch_move_lru()/folios_put_refs() usually hold it for every folio
> > in the batch except the first). However, it's not needed to hold the
> > lruvec lock.
> >
> > The lruvec lock protects folio->lru and the reclaim LRU lists whereas
> > the deferred split queue lives on folio->_deferred_list in
> > deferred_split_lru. The deferred_split_lru is a list_lru with its own
> > per-memcg per-node lock.
> >
> > There are already other existing callers that call
> > folio_unqueue_deferred_split() without holding the lruvec lock (eg
> > __folio_put(), shrink_folio_list(), __folio_migrate_mapping(), ...).
> >
> > Add folio_batch_unqueue_deferred_split() and use it in
> > move_folios_to_lru(), folio_batch_move_lru(), and folios_put_refs() to
> > unqueue each batch of zero-refcount folios from the deferred split list
> > after the lruvec lock is released and before
> > mem_cgroup_uncharge_folios(). This helps shorten the lruvec lock's
> > critical sections, which run with IRQs disabled and are highly
> > contended.
>
> Thanks.
>
> This is a speedup and not a correctness thing, yes?  Let's make it a
> 7.4-rcX thing, for the 7.5 merge window.
>
> I'll park it in the mm-new branch for now.
>
> If people think the speedup is sufficiently worthwhile then I can add a
> cc:stable to it, if clear justification is included in the changelog.

This isn't even a speedup at the moment, as no users have
adopted it yet.

mTHP folios aren't currently added to the deferred split
queue. Joanne is about to add >=2MB mTHP folios to the
deferred split queue again, but even then, contention on
the queue shouldn't be an issue.

It may become a problem someday when we add smaller large
folios, such as 16KB folios, to the deferred split queue.
So this patch is more about future-proofing.

Best Regards
Barry