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

[Alexandre Ghiti]

Hi,

On Wed, Aug 26, 2026 at 3:22 PM Usama Arif <usama.arif@xxxxxxxxx> wrote:
>
> >
> On Tue, 25 Aug 2026 19:24:51 +0200 Alexandre Ghiti <alex@xxxxxxxx> wrote:
>
> > This is a preparatory patch.
> >
> > __swap_cache_alloc_folio() adds the new folio to the LRU itself, which
> > leaves its callers no way to act on the folio before it becomes visible
> > to reclaim.  Two users need exactly that:
> >
> >  - the next patch moves the refault evaluation out of the swap cache
> >    folio allocation, and it has 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;
> >
> >  - the upcoming zswap writeback dropbehind implementation 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.
> >
>
> I think the kernel convention is to not say "next patch" and "upcoming.."
>
> Especially as this patch is in 2 series, so you don't know where it will land.

I have to admit that I don't know how to deal with this shared
patch...I'll drop the references as you suggest and we'll see!

>
> > Defer the LRU insertion to the callers of __swap_cache_alloc_folio():
> > each of them adds the folio right after the allocation, so there is no
> > functional change intended.
> >
> > Suggested-by: Kairui Song <kasong@xxxxxxxxxxx>
> > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
>
>
> The code change itself looks good to me, so once the commit message is fixed:
> Acked-by: Usama Arif <usama.arif@xxxxxxxxx>
>

Thanks for that.

Alex