Re: [PATCH] mm: mglru: clear the reference counter for rejected folios
From: Barry Song
Date: Mon Sep 07 2026 - 22:35:18 EST
On Tue, Sep 8, 2026 at 10:30 AM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
>
> Hi Baolin,
>
> On 09/07/26 at 11:25am, Baolin Wang wrote:
> ......snip...
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 40d3f1b48a74..42c0a09938ab 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
>
> Well, this seems to be based on Andrew's mm-new branch. I usually track
> mm-unstable branch. Maybe the subject should be marked as below?
> [PATCH mm-new] mm: mglru: clear the reference counter for rejected
>
> > @@ -5021,10 +5021,11 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
> > }
> >
> > /* don't add rejected folios to the oldest generation */
> > - if (lru_gen_folio_seq(lruvec, folio, false) == min_seq[type]) {
> > - folio_set_lru_refs(folio, 0);
> > + if (lru_gen_folio_seq(lruvec, folio, false) == min_seq[type])
> > folio_set_active(folio);
> > - }
> > +
> > + /* See the comments on LRU_REFS_FLAGS */
> > + folio_set_lru_refs(folio, 0);
>
> This looks like a great catch, while the code change could bring issue.
>
> Because move_folios_to_lru() relies on folios' flags to decide their new
> generation. You just cleared it before move_folios_to_lru(). This is no
> problem for rejected folios that are determined to be put into the
> oldest generation. But for those rejected folios that are determined to
> be promoted, this could be wrong. E.g currently gen window is 4, and a
> folio is referenced, lru_gen_folio_seq() decides its new gen as 1, which
> is the 2nd oldest generation. While folio_set_lru_refs(folio, 0) clear
> referenced bit, this causes it being put into the oldest generation in
> move_folios_to_lru(), this is not expected.
The original code looks quite weird. It even prioritizes folios
that won't be promoted by `PG_active`. Do we need to change all
the cases just to call `PG_active`?