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

[Lance Yang]

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.

Cheers, Lance