Re: [PATCH v2 4/4] mm: try to free swapcache for non-LRU folios

[Barry Song]

On Wed, Jul 1, 2026 at 4:18 PM David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
[...]
> >
> > The newly allocated folio will likely still be sitting in this
> > CPU's local LRU cache. If we drop the drain in patch 1, it seems
> > there is little point in calling do_wp_page() from
> > do_swap_page(), since we won't be able to reuse the folio while
> > it remains in the local LRU cache.
>
> Well, we call do_wp_page() here to avoid another page fault where we would end
> up in do_wp_page() and actually break COW.

Yep. We still need do_wp_page() to handle CoW, but we could
actually reuse the folio if we don't drop the LRU drain.

>
> >
> > So I'm wondering whether we should keep the drain in
> > patch 1 by checking for a refcount of 3, or instead do
> > something like the following in patch 4:
> >
> >
> >         if ((vmf->flags & FAULT_FLAG_WRITE) && !pte_write(pte)) {
> >                  lru_add_drain();
> >                  ret |= do_wp_page(vmf);
> >                  if (ret & VM_FAULT_ERROR)
> >                          ret &= VM_FAULT_ERROR;
> >        }
> >
> > Otherwise, the combination of patches 1 and 4 seems somewhat
> > inconsistent. It feels like a strange mix of sweet, spicy,
> > hot, and cold—kind of contradictory :-)
>
> Yes, this needs a proper thought.
>
> What you describe is relevant for
>
> e.g.,
>
> swapout
> fork -> exclusive bit cleared
> child exit -> parent is single user
> swapin -> added to swapcache and LRU cache
>
>
> This is not very odd, so we should keep that working (I think I have
> micro-benchmarks for that).

Maybe the simplest approach is to keep the drain in patch 1 and
just make the code improvements you suggested in [1]?

That way, we won't regress the potential reuse in
do_swap_page().

[1] https://lore.kernel.org/all/c4718e32-2baa-4dee-873c-7ab99f21ca4e@xxxxxxxxxx/

Thanks
Barry