Re: [RFC PATCH 1/3] mm: avoid unnecessary lru drain for wp_can_reuse_anon_folio()

From: Shakeel Butt

Date: Wed Jun 17 2026 - 11:29:57 EST


On Fri, Jun 12, 2026 at 09:35:04AM +0800, Barry Song wrote:
> On Fri, Jun 12, 2026 at 2:18 AM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
> >
> > On Thu, Jun 11, 2026 at 11:09:43AM -0700, Shakeel Butt wrote:
> > > On Thu, Jun 11, 2026 at 06:51:22PM +0800, Barry Song (Xiaomi) wrote:
> > > > We always unconditionally drain the LRU before retrying anon folio
> > > > reuse in wp_can_reuse_anon_folio(). Instead, assume !LRU anon folios
> > > > are in lru_cache, and use the refcount to avoid many unnecessary LRU
> > > > drains.
> > > >
> > > > Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
> > > > ---
> > > > mm/memory.c | 8 +++++++-
> > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/mm/memory.c b/mm/memory.c
> > > > index 56be920c56d7..487a34377a7b 100644
> > > > --- a/mm/memory.c
> > > > +++ b/mm/memory.c
> > > > @@ -4193,12 +4193,18 @@ static bool wp_can_reuse_anon_folio(struct folio *folio,
> > > > */
> > > > if (folio_test_ksm(folio) || folio_ref_count(folio) > 3)
> > > > return false;
> > > > - if (!folio_test_lru(folio))
> > > > + if (!folio_test_lru(folio)) {
> > > > + /*
> > > > + * Assume folio is on lru_cache and holds a cache reference.
> > > > + */
> > > > + if (folio_ref_count(folio) > 2 + folio_test_swapcache(folio))
> > > > + return false;
> > >
> > > In your experiments, how much amount of drains were reduced due to this specific
> > > check?
> > >
> > > I wonder if that data can motivate to introduce lru_add_drain_folio(folio) which
> > > only drains if the given folio is in the local lru_add cache.
> >
> > Actually if we can peek into lru_add cache and folio_ref_count(folio) is exactly
> > equal to (2 + folio_test_swapcache(folio)) and folio is not on LRU then we can
> > just reuse folio if it is in lru_add cache without draining, right?
> >
>
> The real problem is that !folio_test_lru(folio) does not tell us
> whether the folio is still sitting in lru_cache, and determining that
> is unlikely to be cheap. We could either scan the lru_cache or add a
> separate flag to indicate lru_cache membership, but neither option
> sounds particularly appealing.

I was thinking of lru_cache scanning. I see this can be 4 cache misses, so might
be expensive. Though if we are draining non-full cache most of the time then it
might be cheaper. Anyways if you don't mind checking the cost that would be
awesome.