Re: [PATCH RFC] mm/mglru: lazily activate folios while folios are really mapped

From: Barry Song

Date: Thu Feb 26 2026 - 19:16:11 EST


Hi Zicheng,

On Thu, Feb 26, 2026 at 8:57 PM wangzicheng <wangzicheng@xxxxxxxxx> wrote:
[...]
> > /**
> > * folio_add_lru - Add a folio to an LRU list.
> > * @folio: The folio to be added to the LRU.
> > @@ -506,7 +519,8 @@ void folio_add_lru(struct folio *folio)
> > /* see the comment in lru_gen_folio_seq() */
> > if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
> > lru_gen_in_fault() && !(current->flags & PF_MEMALLOC))
> > - folio_set_active(folio);
> > + if (!folio_is_file_lru(folio))
> > + folio_set_active(folio);
> >
> > folio_batch_add_and_move(folio, lru_add);
> > }
> > --
> > 2.39.3 (Apple Git-146)
>
> Hi Barry,
>
> Setting only non-filelru-folio in folio_add_lru looks reasonable and
> should help with over-protecting readahead pages that are never
> actually accessed.
>
> For our workloads that already suffer from file under-protection, we see two
> sides here: on the positive side, keeping only actually-used readahead pages
> in memory could improve performance; on the other hand, since we already

Right, the fundamental principle of LRU is to place cold pages at
the tail, not at the head, making cold pages easier to reclaim and
hot pages harder to reclaim.

> see file under-protect issues, it's not clear whether this change might
> exacerbate that or even hurt performance.

I find your concern a bit surprising. If I understand correctly,
you’re observing that file folios are currently being over-reclaimed.
In that case, placing hot pages at the tail might make them harder
to reclaim after PTE scanning (since they may still be young), but
this seems to violate the fundamental principle of LRU. Moreover,
when scanning encounters young file folios, reclaim will simply
continue scanning more folios to find reclaimable ones, so scanning
hot folios only wastes CPU time.
Since read-ahead cold folios are placed at the head, relatively hotter
folios may be reclaimed instead, causing refaults and further triggering
reclaim, which can worsen the situation.

>
> We'll test this when available and report back. We hope to have a
> chance to discuss this topic at LSF/MM/BPF.
>

Sure, thanks!

Barry