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

[Joanne Koong]

On Tue, Oct 13, 2026 at 9:24 PM Lance Yang <lance.yang@xxxxxxxxx> wrote:
>
>
>
> On 2026/10/14 11:13, Barry Song wrote:
> > On Wed, Oct 14, 2026 at 11:07 AM Lance Yang <lance.yang@xxxxxxxxx> wrote:
> >>
> >>
> >> On Tue, Oct 13, 2026 at 03:13:07PM -0700, Joanne Koong 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.
> >>
> >> Nice work! Thanks!
> >>
> >> BTW, have you seen measurable overhead from unqueueing deferred split
> >> folios under the lruvec lock?
> >>
> >> Any before/after numbers for this change, including the cost of the extra
> >> pass over the batch?
> >
> > I recall Joanne mentioning some data on this in the link below. Is that right?
> >
> > https://lore.kernel.org/linux-mm/CAJnrk1a2PpUGTsCgS7jct2KET4K2zAL+_h+te8G1MaU9bXs99w@xxxxxxxxxxxxxx/
>
> Thanks, Barry! Yes, those numbers answer my question about the
> observed overhead :)
>
> Joanne, have you rerun that benchmark with this patch? I'd be
> interested in the before/after runtime and lruvec lock wait.

Hi Lance,

(Thanks Barry for providing the link to the earlier discussion!)

I have not run those benchmarks with this patch yet but I will get
those numbers and add them to v2 when I send that out.

Thanks,
Joanne