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

[Ridong Chen <ridong.chen@linux.dev>]

On 11/12/2026 4:41 PM, Barry Song wrote:
> On Thu, Nov 12, 2026 at 4:38 PM Kairui Song <ryncsn@gmail.com> 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 :-)

Hi Kairui, Barry,

Thanks for taking a look.

Barry is right about the reason. With the classic LRU,
lruvec_add_folio() adds the deactivated folio to the head of the
inactive list. With MGLRU, lruvec_add_folio() can't put an anon folio
into the oldest generation at all: lru_gen_folio_seq() places a
swap-backed folio that is not in the swap cache into max_seq - 1,
regardless of its refs. The only way to reach the oldest generation is
the reclaiming path of lruvec_add_folio_tail(), and that path adds the
folio to the tail.

And you are right that this makes it more aggressive than the classic
LRU. With this patch, a deactivated folio is evicted before the folios
already in the oldest generation, while the classic LRU puts it behind
the folios already on the inactive list. It also changes file folios:
before this patch they are added to the head of the oldest generation,
the same as the classic LRU, and now they go to the tail.

So the problem in the current code is that a deactivated anon folio is
promoted into an active generation, and with this patch it goes one
step further than the classic LRU in the other direction.

-- 
Best regards
Ridong