Re: [PATCH v4 1/3] mm: swap: move LRU insertion out of the swap cache allocator

[Alexandre Ghiti]

Hi Kairui,

On Mon, Sep 14, 2026 at 10:03 AM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> >
> On Fri, Sep 11, 2026 at 5:47 PM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> >
> > This is a preparatory patch.
> >
> > __swap_cache_alloc_folio() adds the new folio to the LRU itself, which
>
> I think you mean:
> "swap_cache_alloc_folio() adds the new folio to the LRU itself"
>
> __swap_cache_alloc_folio is the new name you introduced in this patch.

Oh yes, my sed was too broad :)

>
> > leaves its callers no way to act on the folio before it becomes visible
> > to reclaim.  Two users need exactly that:
> >
> >  - moving the refault evaluation out of the swap cache folio allocation
> >    requires it to happen before folio_add_lru(): that consumes PG_active
> >    to file the folio on the inactive or the active list, and under MGLRU
> >    it also reads PG_workingset to pick the generation.  Setting either
> >    flag afterwards does not move the folio;
> >
> >  - zswap writeback dropbehind needs the buffer folio to stay off the LRU
> >    entirely, as the per-CPU LRU batch would hold a reference on it and
> >    keep remove_mapping() from freeing it once writeback completes.
> >
> > Defer the LRU insertion to the callers of __swap_cache_alloc_folio():
>
> And you defer the LRU insertion and and rename the helper.

I'll reword this, thanks

>
> > each of them adds the folio right after the allocation, so there is no
> > functional change intended.
> >
> > Suggested-by: Kairui Song <kasong@xxxxxxxxxxx>
> > Reviewed-by: Nhat Pham <nphamcs@xxxxxxxxx>
> > Reviewed-by: Kunwu Chan <kunwu.chan@xxxxxxxxx>
> > Acked-by: Usama Arif <usama.arif@xxxxxxxxx>
> > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
> > ---
> >  mm/swap.h       |  6 +++---
> >  mm/swap_state.c | 20 ++++++++++++--------
> >  mm/swapfile.c   |  2 +-
> >  mm/zswap.c      |  5 +++--
> >  4 files changed, 19 insertions(+), 14 deletions(-)
>
> Everything else looks good.
>
> Reviewed-by: Kairui Song <kasong@xxxxxxxxxxx>
>

Great, thanks Kairui!

Alex