Re: [PATCH] mm/mglru: deactivate anon folios into the oldest generation

[Kairui Song]

On Thu, Nov 12, 2026 at 4:42 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> On Thu, Nov 12, 2026 at 4:38 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
> [...]
> > >  mm/folio.c | 11 ++++++++++-
> > >  1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/folio.c b/mm/folio.c
> > > index ea3adb6a89d7..c412d9b398e4 100644
> > > --- a/mm/folio.c
> > > +++ b/mm/folio.c
> > > @@ -583,7 +583,16 @@ static void lru_deactivate(struct lruvec *lruvec, struct folio *folio)
> > >       lruvec_del_folio(lruvec, folio);
> > >       folio_clear_active(folio);
> > >       folio_clear_referenced(folio);
> > > -     lruvec_add_folio(lruvec, folio);
> > > +     /*
> > > +      * For MGLRU, lruvec_add_folio() places anon folios that are not in
> > > +      * the swap cache into the second youngest generation, which is an
> > > +      * active one. Add the folio to the oldest generation instead, like
> > > +      * lru_deactivate_file() does for clean folios.
> > > +      */
> > > +     if (lru_gen_enabled())
> > > +             lruvec_add_folio_tail(lruvec, folio);
> > > +     else
> > > +             lruvec_add_folio(lruvec, folio);
> >
> > Hi Ridong,
> >
> > One question here, why MGLRU/CLRU have to use two different ways to
> > add the folio back?  Will this cause over aggressive reclaim of the
> > folio?
>
> I guess that is because on mglru, that is lacing a way to add the folio to
> the head of the oldest generation for anon folios while CLRU can do
> that :-)

Right, but lruvec_add_folio_tail also added the folio to the very tail
of the inactive / oldest list, could it be a gain or problem if we do
that too for CLRU?