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

[Lance Yang]

On 2026/10/17 08:45, 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.
>
> Signed-off-by: Joanne Koong <joannelkoong@xxxxxxxxx>
> ---
> This patch came out of a discussion about splitting underused mTHP folios [1],
> where queueing small mTHP folios on the deferred split list was found to
> regress Barry's fault microbenchmark. The cost turned out to be the unqueue
> running under the lruvec lock rather than contention on the deferred split
> queue itself. Testing this patch on top of the series in [1] with the same
> microbenchmark, queueing every 16k folio went from a 15% runtime cost to
> noise, with lruvec lock wait dropping from 491 seconds to 38 seconds (most of
> that contention then moves to the deferred split list_lru lock, but runtime
> still drops back to the unqueued baseline).

Looks great :) Could you also keep the benchmark results above the '---'?
They'd be useful to have in the changelog, along with the test setup.

With that, LGTM!

Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>