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

Alexandre Ghiti <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <CAEmasaXU9n2Kxjf-+gvjevGJ6LS0EU8fWWHtb09SDEi3phUJmw@mail.gmail.com>
Hi Barry,

On Sun, Aug 23, 2026 at 10:39 AM Barry Song <[email protected]> wrote:
>
> >
> On Fri, Aug 21, 2026 at 5:37 PM Alexandre Ghiti <[email protected]> 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 <[email protected]>
> > Signed-off-by: Alexandre Ghiti <[email protected]>
>
> 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/[email protected]/
>
> 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.