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 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 :)

Thanks, Barry, for all your comments.

Alex

>
> Thanks
> Barry
>