Re: [RFC PATCH] mm/mglru: Avoid reclaiming kept folios during retrying missed rotated folios

[Kairui Song <ryncsn@gmail.com>]

On Thu, Oct 08, 2026 at 02:52:35PM +0100, Baolin Wang wrote:
> Hi Barry,
> 
> On 10/3/26 1:42 PM, Barry Song (Xiaomi) wrote:
> > Since commit 4d5d14a01e2c ("mm/mglru: rework workingset protection"),
> > `folio_test_referenced()` was accidentally removed when checking for
> > missed rotated folios. As a result, kept folios without an active set
> > could be added to the retry list and eventually reclaimed.
> > 
> > The impact should be very small, as we have the `folio_mapped(folio)`
> > check before retrying. Kept folios won't have `try_to_unmap()` called,
> > so this is really only applicable to folios that are unmapped by users
> > after `folio_referenced()` has been called.
> > 
> > I'm not sure if anyone else has seen any issues with this. Sending an
> > RFC to check whether it is worth fixing.
> > 
> > Fixes: 4d5d14a01e2c ("mm/mglru: rework workingset protection")
> > Cc: Yu Zhao <yuzhao@google.com>
> > Reported-by: Bo Zhang <zhangbo56@xiaomi.com>
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > ---
> >   mm/vmscan.c | 7 +++++--
> >   1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 91295070ca33..6a931b576b7d 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -994,8 +994,10 @@ static enum folio_references folio_check_references(struct folio *folio,
> >   		return FOLIOREF_KEEP;
> >   	if (lru_gen_enabled() && !lru_gen_switching()) {
> > -		if (!referenced_ptes)
> > +		if (!referenced_ptes) {
> > +			folio_clear_referenced(folio);
> >   			return FOLIOREF_RECLAIM;
> > +		}
> 
> I've also been investigating the issue of referenced folios being reclaimed
> recently. The background is that classical LRU will return FOLIOREF_KEEP for
> folios accessed once via page table, giving the accessed folio another
> chance.

Hi, thanks for looking into this.

> 
> However, for MGLRU, if the folio's pagetable access has already been
> consumed by aging or lru_gen_look_around(), referenced_ptes may be 0 at that
> point, leading to reclaiming folios that were accessed via page table, which
> could cause more refaults (I don't have data yet).

If we go with MGLRU-FG, aging or lru_gen_look_around may move the folio
to newer gen which is identical to the behavior of promoting at eviction
time.

> But it's not easy to maintain logic consistent with classical LRU, because
> we cannot distinguish whether this one access count comes from page table or
> file descriptors (for anonymous pages, it can be distinguished). I'm not
> sure if Kairui's MGLRU-FG patchset helps with this case (I haven't looked at
> it carefully yet).

It definatly helps, check this one:
https://lore.kernel.org/linux-mm/20261003-mglru-fg-v3-4-cbd4546a5bd9@tencent.com/

folio_inc_lru_refs and variants will promote the folios in a consistent way.
See "First access only defers eviction from the oldest gen" part, I believe
that is the issue you worries about?

BTW promote then to newest gen directly does over protect them, I've see
regression with that.

> 
> Perhaps at least for anonymous pages, if the referenced flag is set, we
> should return FOLIOREF_KEEP to give it another scan chance.

No I think we really shouldn't do that, it will over protect single used
folios. Promoting them to second newest gen or second oldest gen seems
a good idea and similiar to CLRU, and this is the behavior of MGLRU-FG.