Re: [PATCH 0/4] mm/vmscan: refactor shrink_folio_list()

[Barry Song]

On Sun, Sep 20, 2026 at 10:25 PM Zhang Peng <zippermonkey@xxxxxxxxxx> wrote:
>
> shrink_folio_list() has grown into a very long function whose body mixes
> several independent concerns: folio activation, the pageout() dispatch
> state machine, the unmap step, and the final freeing path.  The control
> flow between them is expressed entirely through a chain of goto labels
> (activate_locked, activate_locked_split, keep_locked, keep), which makes
> it hard to see which decision each block actually reaches.
>
> This series extracts four self-contained blocks into helpers, without
> changing behaviour:
>
>   Patch 1: the activation block at activate_locked, into
>            folio_activate_locked().
>   Patch 2: the freeing path (buffer release, lazyfree, __remove_mapping,
>            folio_batch drain), into folio_try_reclaim_free().
>   Patch 3: the pageout() dispatch state machine, into
>            folio_try_pageout().
>   Patch 4: the TTU setup and try_to_unmap() block, into
>            folio_try_unmap().
>
> Rather than returning a boolean, the extracted helpers return an explicit
> result enum, so the reclaim decisions the caller has to make - activate,
> keep, or reclaimed - stay visible at the call site instead of being
> buried in the helper.  Where a folio may be returned either locked or
> unlocked, the result also records which, so the caller does not have to
> infer the lock state from an invisible internal decision.
>
> This is preparation for batching the dirty TLB flush before pageout,
> which needs to call the pageout path from a second place.  That change
> will be posted separately once this cleanup has landed [1].
>
> No functional change intended.
>
> [1] https://lore.kernel.org/all/CAGsJ_4wrQRGjqavMzWgi2+PrRr1ztf4QRZEb6HKm02OF8nEBUQ@xxxxxxxxxxxxxx/
>
> Suggested-by: Kairui Song <kasong@xxxxxxxxxxx>
> Signed-off-by: Zhang Peng <bruzzhang@xxxxxxxxxxx>
> ---

Hi Peng,

As suggested, I think it would be better to include patch 5
("[PATCH v5 5/5] mm/vmscan: flush TLB for every 31 folios
evictions")[1] in the same series as patches 1–4, since
patches 1–4 don't really stand on their own without patch 5.

The whole series is a really good idea.
Looking forward to the next version.

[1] https://lore.kernel.org/linux-mm/20260720-batch-tlb-flush-v5-5-db943a0d0d6b@xxxxxxxxxx/

Best Regards
Barry