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

[David Hildenbrand (Arm)]

On 10/21/26 00:36, Andrew Morton 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.

I'll pick this up for the next merge window.

-- 
Cheers,

David