Re: [PATCH mm-new v2] mm: mglru: clear the reference counter for rejected folios

[Baolin Wang]

On 9/14/26 4:09 PM, Kairui Song wrote:
> On Wed, Sep 9, 2026 at 9:57 AM Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
> > As per the comment on LRU_REFS_FLAGS, when accessed folios are promoted to
> > a new generation, LRU_REFS_FLAGS should be cleared so that the reference
> > counter can start over.
> >
> > For folios rejected by shrink_folio_list(), we clear LRU_REFS_FLAGS and
> > set the PG_active flag when lru_gen_folio_seq() would place them in the
> > oldest generation. That's fine.
> >
> > But for rejected folios where lru_gen_folio_seq() returns a generation
> > other than the oldest one (which can be treated as a promotion), we do
> > not clear LRU_REFS_FLAGS. This can violate the promotion mechanism. And
> > this means the rejected folio enters the new generation with stale, inflated
> > tier bits, which can inflate reference counts and distort eviction
> > statistics for these rejected folios.
> >
> > Fix this by clearing LRU_REFS_FLAGS for rejected folios. Of course, I need
> > to evaluate the impact of the changes, which mainly falls into 3 cases:
> > 1. When lru_gen_folio_seq() returns the oldest generation for rejected folios,
> > there are no logic changes, and they will be put back into the 2nd youngest
> > generation.
> > 2. For rejected folios with PG_active set by shrink_folio_list(), we only
> > clear the LRU_REFS_FLAGS and do not change the generation.
> > 3. For rejected folios with PG_referenced set, the original code would put
> > them back into the 2nd oldest generation. After this patch, we will put them
> > back into the 2nd youngest generation.
> >
> > I think case 3 is also reasonable, before commmit 6cbdd9726fb5 ("mm/mglru:
> > use folio_mark_accessed to replace folio_set_active"), a rejected referenced
> > folio was also put back to the 2nd youngest gen. Meanwhile, I didn't see
> > any noticeable performance impact on my 32-core Arm machine when running
> > 'make -j32' to build the kernel inside a 3G-limited memcg with either zram
> > or NVMe swap.
> >
> > Signed-off-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> > ---
> > Changes from v1:
> >   - Update the commit message.
> >   - Clear LRU_REFS_FLAGS earlier.
> > ---
> >   mm/vmscan.c | 7 ++++---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 40d3f1b48a74..1557679aadb1 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -5020,11 +5020,12 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
> >                          continue;
> >                  }
> >
> > +               /* See the comments on LRU_REFS_FLAGS */
> > +               folio_set_lru_refs(folio, 0);
> > +
>
> Will it be better to mention that we never add the folio to the oldest
> gen (since `folio_set_active` below prevents that) so this is
> effectively promotes the folio by at least one generation? Maybe can
> be combined with the comment below.

OK. How about the following comments?

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c2eb8fa9d5e5..a1ead7c61054 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -5071,10 +5071,13 @@ static int evict_folios(unsigned long 
nr_to_scan, struct lruvec *lruvec,
                        continue;
                }

-               /* See the comments on LRU_REFS_FLAGS */
+               /*
+                * See the comments on LRU_REFS_FLAGS.
+                *
+                * The rejected folios are never added to the oldest 
generation,
+                * so this effectively promotes them by at least one 
generation.
+                */
                folio_set_lru_refs(folio, 0);
-
-               /* don't add rejected folios to the oldest generation */
                if (lru_gen_folio_seq(lruvec, folio, false) == 
min_seq[type])
                        folio_set_active(folio);
        }

> >                  /* 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);
> > -               }
> >          }
> >
> >          move_folios_to_lru(&list);
> > --
> > 2.47.3
>
> I tested this, and also tested with MGLRU-FG on top (the posted
> version is on top of this):
> https://lore.kernel.org/linux-mm/20260911-mglru-fg-v2-4-f26e5cb26da7@xxxxxxxxxxx/
>
> Both cases looked good with no performance regression observed from
> this patch with a few quick tests. It also has no conflict with
> further changes. Nothing surprising was observed, so:

Great. Thanks for testing.

> Reviewed-by: Kairui Song <kasong@xxxxxxxxxxx>