Re: [PATCH] mm/lruvec: preemptively free dead folios during lru_add drain

[Shakeel Butt]

On Thu, Apr 23, 2026 at 02:18:16PM -0700, JP Kobryn (Meta) wrote:
> On 4/23/26 11:46 AM, Shakeel Butt wrote:
> > On Thu, Apr 23, 2026 at 09:43:07AM -0700, JP Kobryn (Meta) wrote:
> > > Of all observable lruvec lock contention in our fleet, we find that ~24%
> > > occurs when dead folios are present in lru_add batches at drain time.
> > 
> > So, when they were added to the percpu lru cache, they were alive but during
> > their stay in lru cache, they were freed (last non-lrucache ref dropped) or
> > somehow we are adding folio where the caller drops the reference just after
> > adding to percpu lru cache e.g. folio_putback_lru() ?
> 
> Both scenarios can occur. Whether all callers put the folio while it is
> on the per-cpu batch or putback drops ref from 2 to 1, the batch ref
> is what remains.

I was wondering which one is dominant.

> 
> [...]
> > 
> > Overall the code looks good but I do wonder if we can add something similar to
> > folio_add_lru() and if that would be enough.
> 
> folio_add_lru() is how it gets onto the batch. But it's still alive at
> that point - at least one caller ref.

Yeah, I was thinking if we do special checking at folio_putback_lru() to avoid
folio_add_lru() at all (only if folio_putback_lru() is the one causing such
scenario most of the time).

Anyways, that analysis can be done later. So, for the path:

Acked-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>