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

[Lance Yang <lance.yang@linux.dev>]

On 2026/10/14 11:13, Barry Song wrote:
> On Wed, Oct 14, 2026 at 11:07 AM Lance Yang <lance.yang@linux.dev> 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@mail.gmail.com/

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