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

[Barry Song]

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/

Best Regards
Barry