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

[Alexandre Ghiti]

Hi Barry,

On Sun, Aug 23, 2026 at 2:16 PM Alexandre Ghiti <alexghiti@xxxxxxxx> wrote:
>
> Hi Barry,
>
> On Sun, Aug 23, 2026 at 10:39 AM Barry Song <baohua@xxxxxxxxxx> wrote:
> >
> > > >
> > On Fri, Aug 21, 2026 at 5:37 PM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> > >
> > > The swap cache allocator adds the new folio to the LRU itself, which
> > > forces every caller to live with that ordering.  The next patch needs to
> > > evaluate the refault of a swapped-in folio *before* it becomes visible to
> > > reclaim, because folio_add_lru() consumes PG_workingset/PG_active when it
> > > picks the LRU list (and, under MGLRU, the generation).
> > >
> > > So defer the LRU addition to the callers of __swap_cache_alloc_folio(),
> > > no functional change intended.
> > >
> > > Suggested-by: Kairui Song <kasong@xxxxxxxxxxx>
> > > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
> >
> > Hi Alexandre,
> >
> > I’m getting a bit confused, as I noticed that you also have this
> > patch in another patchset:
> >
> > https://lore.kernel.org/linux-mm/20260818163221.589352-2-alex@xxxxxxxx/
> >
> > Why are you including the same patch in two different patchsets?
>
> Sorry for the confusion, I explained it in the cover letter but should
> have explicitly answered Sashiko's review on v1.
>
> Sashiko pointed out that moving workingset_refault() out of
> __swap_cache_alloc_folio() breaks MGLRU folio placement:
>
> "swap_cache_alloc_folio() calls folio_add_lru() which places the folio
> in the per-CPU lru addition batch. If this batch drains before
> workingset_refault() executes, lru_gen_add_folio() calculates the
> generation without PG_workingset being set, placing the folio in an older,
> suboptimal generation."
>
> https://sashiko.dev/#/patchset/20260817144622.137133-1-alex%40ghiti.fr
>
> But good news is that v5 of dropbehing will drop this patch :)

Nope, correcting myself here: I need to keep the zswap writeback
folios off-lru because folio_add_lru() puts the folio onto the percpu
lru batch which holds a reference and for synchronous devices, this
reference prevents the folio from being freed by remove_mapping() (it
certainly happens to asynchronous devices too).

I have just sent v4 of dropbehind.

Thanks again,

Alex

>
> Thanks, Barry, for all your comments.
>
> Alex
>
> >
> > Thanks
> > Barry
> >