Re: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU

Re: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU

[Barry Song]

On Thu, Aug 13, 2026 at 7:02 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>
> From: Ridong Chen <chenridong@xiaomi.com>
>
> When the LRU is switched to MGLRU (echo y > /sys/kernel/mm/lru_gen/
> enabled), fill_evictable() re-inserts every folio via
> lru_gen_add_folio(..., false).  With reclaiming hardcoded to false, an
> inactive anonymous folio (no PG_active, not in the swapcache) takes the
> "gen = MIN_NR_GENS" branch in lru_gen_folio_seq() and is seeded at
> seq = max_seq - 1, which lru_gen_is_active() treats as active.  Its
> inactive placement is lost and NR_INACTIVE_ANON is folded into
> NR_ACTIVE_ANON.
>
> Pass reclaiming=!active so a folio from an inactive list is seeded into
> an older generation.  Folios from the active list carry PG_active and
> hit the first branch either way, so they are unchanged.
>
> Tested on x86_64, next-20260812, 2G VM + 1G swap, ~1.5G anon pushed onto
> the inactive list before enabling MGLRU:
>
>                          Active(anon)  Inactive(anon)
>   before switch (legacy)        2952         1548792   kB
>   after `echo y`, unpatched  1552052               0   kB
>   after `echo y`, patched      15144         1536636   kB
>
> Inactive file folios stay inactive either way (NR_INACTIVE_FILE is
> preserved).
>
> Fixes: 354ed5974429 ("mm: multi-gen LRU: kill switch")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> ---
>  mm/vmscan.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 94fc4f25e99f..2befc8d7dd3f 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -5319,7 +5319,12 @@ static bool fill_evictable(struct lruvec *lruvec)
>                         VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio);
>
>                         lruvec_del_folio(lruvec, folio);
> -                       success = lru_gen_add_folio(lruvec, folio, false);
> +                       /*
> +                        * Keep a folio from the inactive list inactive:
> +                        * pass reclaiming=!active so it is not seeded as
> +                        * active.  See lru_gen_folio_seq().
> +                        */
> +                       success = lru_gen_add_folio(lruvec, folio, !active);

This is a very interesting use of the reclaim argument, as it is not
intended to serve this MGLRU switch purpose. It is really only meant
for `folio_rotate_reclaimable()`.

However, the change itself seems to be *partially* correct and
*partially* wrong.

One real issue is that inactive is always placed in the oldest
generation, while we have two old generations. Maybe we can ignore
this for now.

but somehow, are we also inverting the cold/hot ordering in the
inactive list?

`lru_to_folio(head)` always takes the tail, but now we are putting the
tail before the head folios.

Because reclaim == true will use list_add_tail().

if (reclaiming)
list_add_tail(&folio->lru, &lrugen->folios[gen][type][zone]);


> VM_WARN_ON_ONCE(!success);
>
> if (!--remaining)
> --
> 2.34.1
>


Thanks
Barry

Re: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU

[Barry Song]

On Thu, Aug 13, 2026 at 7:24 PM Barry Song <baohua@kernel.org> wrote:
>
> On Thu, Aug 13, 2026 at 7:02 PM Ridong Chen <ridong.chen@linux.dev> wrote:
> >
> > From: Ridong Chen <chenridong@xiaomi.com>
> >
> > When the LRU is switched to MGLRU (echo y > /sys/kernel/mm/lru_gen/
> > enabled), fill_evictable() re-inserts every folio via
> > lru_gen_add_folio(..., false).  With reclaiming hardcoded to false, an
> > inactive anonymous folio (no PG_active, not in the swapcache) takes the
> > "gen = MIN_NR_GENS" branch in lru_gen_folio_seq() and is seeded at
> > seq = max_seq - 1, which lru_gen_is_active() treats as active.  Its
> > inactive placement is lost and NR_INACTIVE_ANON is folded into
> > NR_ACTIVE_ANON.
> >
> > Pass reclaiming=!active so a folio from an inactive list is seeded into
> > an older generation.  Folios from the active list carry PG_active and
> > hit the first branch either way, so they are unchanged.
> >
> > Tested on x86_64, next-20260812, 2G VM + 1G swap, ~1.5G anon pushed onto
> > the inactive list before enabling MGLRU:
> >
> >                          Active(anon)  Inactive(anon)
> >   before switch (legacy)        2952         1548792   kB
> >   after `echo y`, unpatched  1552052               0   kB
> >   after `echo y`, patched      15144         1536636   kB
> >
> > Inactive file folios stay inactive either way (NR_INACTIVE_FILE is
> > preserved).
> >
> > Fixes: 354ed5974429 ("mm: multi-gen LRU: kill switch")
> > Assisted-by: Claude:claude-opus-4-8
> > Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> > ---
> >  mm/vmscan.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 94fc4f25e99f..2befc8d7dd3f 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -5319,7 +5319,12 @@ static bool fill_evictable(struct lruvec *lruvec)
> >                         VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio);
> >
> >                         lruvec_del_folio(lruvec, folio);
> > -                       success = lru_gen_add_folio(lruvec, folio, false);
> > +                       /*
> > +                        * Keep a folio from the inactive list inactive:
> > +                        * pass reclaiming=!active so it is not seeded as
> > +                        * active.  See lru_gen_folio_seq().
> > +                        */
> > +                       success = lru_gen_add_folio(lruvec, folio, !active);
>
> This is a very interesting use of the reclaim argument, as it is not
> intended to serve this MGLRU switch purpose. It is really only meant
> for `folio_rotate_reclaimable()`.
>
> However, the change itself seems to be *partially* correct and
> *partially* wrong.
>
> One real issue is that inactive is always placed in the oldest
> generation, while we have two old generations. Maybe we can ignore
> this for now.
>
> but somehow, are we also inverting the cold/hot ordering in the
> inactive list?
>
> `lru_to_folio(head)` always takes the tail, but now we are putting the
> tail before the head folios.
>
> Because reclaim == true will use list_add_tail().
>
> if (reclaiming)
> list_add_tail(&folio->lru, &lrugen->folios[gen][type][zone]);

I guess we can fix this by iterating in `fill_evictable()` from head
to tail order.

  struct list_head *pos = head->next;

  while (pos != head) {
   struct folio *folio = list_entry(pos, struct folio, lru);
    ...
 }

Then the oldest generation will maintain the same folio order as the
inactive list.

Thanks
Barry

Re: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU

[Ridong Chen]

On 8/13/2026 7:37 PM, Barry Song wrote:
> On Thu, Aug 13, 2026 at 7:24 PM Barry Song <baohua@kernel.org> wrote:
>>
>> On Thu, Aug 13, 2026 at 7:02 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>
>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>
>>> When the LRU is switched to MGLRU (echo y > /sys/kernel/mm/lru_gen/
>>> enabled), fill_evictable() re-inserts every folio via
>>> lru_gen_add_folio(..., false).  With reclaiming hardcoded to false, an
>>> inactive anonymous folio (no PG_active, not in the swapcache) takes the
>>> "gen = MIN_NR_GENS" branch in lru_gen_folio_seq() and is seeded at
>>> seq = max_seq - 1, which lru_gen_is_active() treats as active.  Its
>>> inactive placement is lost and NR_INACTIVE_ANON is folded into
>>> NR_ACTIVE_ANON.
>>>
>>> Pass reclaiming=!active so a folio from an inactive list is seeded into
>>> an older generation.  Folios from the active list carry PG_active and
>>> hit the first branch either way, so they are unchanged.
>>>
>>> Tested on x86_64, next-20260812, 2G VM + 1G swap, ~1.5G anon pushed onto
>>> the inactive list before enabling MGLRU:
>>>
>>>                           Active(anon)  Inactive(anon)
>>>    before switch (legacy)        2952         1548792   kB
>>>    after `echo y`, unpatched  1552052               0   kB
>>>    after `echo y`, patched      15144         1536636   kB
>>>
>>> Inactive file folios stay inactive either way (NR_INACTIVE_FILE is
>>> preserved).
>>>
>>> Fixes: 354ed5974429 ("mm: multi-gen LRU: kill switch")
>>> Assisted-by: Claude:claude-opus-4-8
>>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
>>> ---
>>>   mm/vmscan.c | 7 ++++++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>>> index 94fc4f25e99f..2befc8d7dd3f 100644
>>> --- a/mm/vmscan.c
>>> +++ b/mm/vmscan.c
>>> @@ -5319,7 +5319,12 @@ static bool fill_evictable(struct lruvec *lruvec)
>>>                          VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio);
>>>
>>>                          lruvec_del_folio(lruvec, folio);
>>> -                       success = lru_gen_add_folio(lruvec, folio, false);
>>> +                       /*
>>> +                        * Keep a folio from the inactive list inactive:
>>> +                        * pass reclaiming=!active so it is not seeded as
>>> +                        * active.  See lru_gen_folio_seq().
>>> +                        */
>>> +                       success = lru_gen_add_folio(lruvec, folio, !active);
>>

Hi Barry, Thank you for your reply.

>> This is a very interesting use of the reclaim argument, as it is not
>> intended to serve this MGLRU switch purpose. It is really only meant
>> for `folio_rotate_reclaimable()`.
>>

Yeah, I realize tying the reclaim argument to the MGLRU switch is a bit of a 
hack, since it was really only designed for folio_rotate_reclaimable(). That 
said, I'm not blind to it, I just posted an RFC patch to get the discussion 
rolling and see what people think.

>> However, the change itself seems to be *partially* correct and
>> *partially* wrong.
>>
>> One real issue is that inactive is always placed in the oldest
>> generation, while we have two old generations. Maybe we can ignore
>> this for now.
>>
>> but somehow, are we also inverting the cold/hot ordering in the
>> inactive list?
>>
>> `lru_to_folio(head)` always takes the tail, but now we are putting the
>> tail before the head folios.
>>
>> Because reclaim == true will use list_add_tail().
>>
>> if (reclaiming)
>> list_add_tail(&folio->lru, &lrugen->folios[gen][type][zone]);
> 
> I guess we can fix this by iterating in `fill_evictable()` from head
> to tail order.
> 
>    struct list_head *pos = head->next;
> 
>    while (pos != head) {
>     struct folio *folio = list_entry(pos, struct folio, lru);
>      ...
>   }
> 
> Then the oldest generation will maintain the same folio order as the
> inactive list.
> 
Thanks for the suggestion. Traversing head to tail does fix the inversion, but 
we need to distinguish active from inactive during iteration, because they are 
inserted differently: list_add_tail() when reclaiming, and list_add() otherwise. 
That said, the reclaim argument usage still feels off to me—I'd like to hear if 
others have a better idea before we proceed with further changes.

-- 
Best regards
Ridong

Re: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU

[Barry Song]

On Fri, Aug 14, 2026 at 10:22 AM Ridong Chen <ridong.chen@linux.dev> wrote:
>
>
>
> On 8/13/2026 7:37 PM, Barry Song wrote:
> > On Thu, Aug 13, 2026 at 7:24 PM Barry Song <baohua@kernel.org> wrote:
> >>
> >> On Thu, Aug 13, 2026 at 7:02 PM Ridong Chen <ridong.chen@linux.dev> wrote:
> >>>
> >>> From: Ridong Chen <chenridong@xiaomi.com>
> >>>
> >>> When the LRU is switched to MGLRU (echo y > /sys/kernel/mm/lru_gen/
> >>> enabled), fill_evictable() re-inserts every folio via
> >>> lru_gen_add_folio(..., false).  With reclaiming hardcoded to false, an
> >>> inactive anonymous folio (no PG_active, not in the swapcache) takes the
> >>> "gen = MIN_NR_GENS" branch in lru_gen_folio_seq() and is seeded at
> >>> seq = max_seq - 1, which lru_gen_is_active() treats as active.  Its
> >>> inactive placement is lost and NR_INACTIVE_ANON is folded into
> >>> NR_ACTIVE_ANON.
> >>>
> >>> Pass reclaiming=!active so a folio from an inactive list is seeded into
> >>> an older generation.  Folios from the active list carry PG_active and
> >>> hit the first branch either way, so they are unchanged.
> >>>
> >>> Tested on x86_64, next-20260812, 2G VM + 1G swap, ~1.5G anon pushed onto
> >>> the inactive list before enabling MGLRU:
> >>>
> >>>                           Active(anon)  Inactive(anon)
> >>>    before switch (legacy)        2952         1548792   kB
> >>>    after `echo y`, unpatched  1552052               0   kB
> >>>    after `echo y`, patched      15144         1536636   kB
> >>>
> >>> Inactive file folios stay inactive either way (NR_INACTIVE_FILE is
> >>> preserved).
> >>>
> >>> Fixes: 354ed5974429 ("mm: multi-gen LRU: kill switch")
> >>> Assisted-by: Claude:claude-opus-4-8
> >>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> >>> ---
> >>>   mm/vmscan.c | 7 ++++++-
> >>>   1 file changed, 6 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/mm/vmscan.c b/mm/vmscan.c
> >>> index 94fc4f25e99f..2befc8d7dd3f 100644
> >>> --- a/mm/vmscan.c
> >>> +++ b/mm/vmscan.c
> >>> @@ -5319,7 +5319,12 @@ static bool fill_evictable(struct lruvec *lruvec)
> >>>                          VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio);
> >>>
> >>>                          lruvec_del_folio(lruvec, folio);
> >>> -                       success = lru_gen_add_folio(lruvec, folio, false);
> >>> +                       /*
> >>> +                        * Keep a folio from the inactive list inactive:
> >>> +                        * pass reclaiming=!active so it is not seeded as
> >>> +                        * active.  See lru_gen_folio_seq().
> >>> +                        */
> >>> +                       success = lru_gen_add_folio(lruvec, folio, !active);
> >>
>
> Hi Barry, Thank you for your reply.
>
> >> This is a very interesting use of the reclaim argument, as it is not
> >> intended to serve this MGLRU switch purpose. It is really only meant
> >> for `folio_rotate_reclaimable()`.
> >>
>
> Yeah, I realize tying the reclaim argument to the MGLRU switch is a bit of a
> hack, since it was really only designed for folio_rotate_reclaimable(). That
> said, I'm not blind to it, I just posted an RFC patch to get the discussion
> rolling and see what people think.

I think it’s fine. Just update the comment there and mention that it
can serve another purpose as well.

[...]
> > Then the oldest generation will maintain the same folio order as the
> > inactive list.
> >
> Thanks for the suggestion. Traversing head to tail does fix the inversion, but
> we need to distinguish active from inactive during iteration, because they are
> inserted differently: list_add_tail() when reclaiming, and list_add() otherwise.
> That said, the reclaim argument usage still feels off to me—I'd like to hear if
> others have a better idea before we proceed with further changes.

We can change reclaim to a tristate integer, or simply make the
following change and add a comment explaining why?

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9e52f49114e7..5e624d0316bc 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -5403,7 +5403,8 @@ static bool fill_evictable(struct lruvec *lruvec)

                while (!list_empty(head)) {
                        bool success;
-                       struct folio *folio = lru_to_folio(head);
+                       struct folio *folio = active ? lru_to_folio(head) :
+                               list_entry((head)->next, struct folio, lru);

Or you could even move the entire inactive list to the oldest gen
instead of moving the folios one by one. Then you can avoid dealing
with the reclaim argument entirely.

Best Regards
Barry

Re: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU

[Ridong Chen]

On 8/14/2026 10:31 AM, Barry Song wrote:
> On Fri, Aug 14, 2026 at 10:22 AM Ridong Chen <ridong.chen@linux.dev> wrote:
>>
>>
>>
>> On 8/13/2026 7:37 PM, Barry Song wrote:
>>> On Thu, Aug 13, 2026 at 7:24 PM Barry Song <baohua@kernel.org> wrote:
>>>>
>>>> On Thu, Aug 13, 2026 at 7:02 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>>>
>>>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>>>
>>>>> When the LRU is switched to MGLRU (echo y > /sys/kernel/mm/lru_gen/
>>>>> enabled), fill_evictable() re-inserts every folio via
>>>>> lru_gen_add_folio(..., false).  With reclaiming hardcoded to false, an
>>>>> inactive anonymous folio (no PG_active, not in the swapcache) takes the
>>>>> "gen = MIN_NR_GENS" branch in lru_gen_folio_seq() and is seeded at
>>>>> seq = max_seq - 1, which lru_gen_is_active() treats as active.  Its
>>>>> inactive placement is lost and NR_INACTIVE_ANON is folded into
>>>>> NR_ACTIVE_ANON.
>>>>>
>>>>> Pass reclaiming=!active so a folio from an inactive list is seeded into
>>>>> an older generation.  Folios from the active list carry PG_active and
>>>>> hit the first branch either way, so they are unchanged.
>>>>>
>>>>> Tested on x86_64, next-20260812, 2G VM + 1G swap, ~1.5G anon pushed onto
>>>>> the inactive list before enabling MGLRU:
>>>>>
>>>>>                            Active(anon)  Inactive(anon)
>>>>>     before switch (legacy)        2952         1548792   kB
>>>>>     after `echo y`, unpatched  1552052               0   kB
>>>>>     after `echo y`, patched      15144         1536636   kB
>>>>>
>>>>> Inactive file folios stay inactive either way (NR_INACTIVE_FILE is
>>>>> preserved).
>>>>>
>>>>> Fixes: 354ed5974429 ("mm: multi-gen LRU: kill switch")
>>>>> Assisted-by: Claude:claude-opus-4-8
>>>>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
>>>>> ---
>>>>>    mm/vmscan.c | 7 ++++++-
>>>>>    1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>>>>> index 94fc4f25e99f..2befc8d7dd3f 100644
>>>>> --- a/mm/vmscan.c
>>>>> +++ b/mm/vmscan.c
>>>>> @@ -5319,7 +5319,12 @@ static bool fill_evictable(struct lruvec *lruvec)
>>>>>                           VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio);
>>>>>
>>>>>                           lruvec_del_folio(lruvec, folio);
>>>>> -                       success = lru_gen_add_folio(lruvec, folio, false);
>>>>> +                       /*
>>>>> +                        * Keep a folio from the inactive list inactive:
>>>>> +                        * pass reclaiming=!active so it is not seeded as
>>>>> +                        * active.  See lru_gen_folio_seq().
>>>>> +                        */
>>>>> +                       success = lru_gen_add_folio(lruvec, folio, !active);
>>>>
>>
>> Hi Barry, Thank you for your reply.
>>
>>>> This is a very interesting use of the reclaim argument, as it is not
>>>> intended to serve this MGLRU switch purpose. It is really only meant
>>>> for `folio_rotate_reclaimable()`.
>>>>
>>
>> Yeah, I realize tying the reclaim argument to the MGLRU switch is a bit of a
>> hack, since it was really only designed for folio_rotate_reclaimable(). That
>> said, I'm not blind to it, I just posted an RFC patch to get the discussion
>> rolling and see what people think.
> 
> I think it’s fine. Just update the comment there and mention that it
> can serve another purpose as well.
> 
> [...]
>>> Then the oldest generation will maintain the same folio order as the
>>> inactive list.
>>>
>> Thanks for the suggestion. Traversing head to tail does fix the inversion, but
>> we need to distinguish active from inactive during iteration, because they are
>> inserted differently: list_add_tail() when reclaiming, and list_add() otherwise.
>> That said, the reclaim argument usage still feels off to me—I'd like to hear if
>> others have a better idea before we proceed with further changes.
> 
> We can change reclaim to a tristate integer, or simply make the
> following change and add a comment explaining why?
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 9e52f49114e7..5e624d0316bc 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -5403,7 +5403,8 @@ static bool fill_evictable(struct lruvec *lruvec)
> 
>                  while (!list_empty(head)) {
>                          bool success;
> -                       struct folio *folio = lru_to_folio(head);
> +                       struct folio *folio = active ? lru_to_folio(head) :
> +                               list_entry((head)->next, struct folio, lru);
> 

I've sent a new patch following this approach.

Link: 
https://lore.kernel.org/linux-mm/20260820072641.253591-1-ridong.chen@linux.dev/T/#u

> Or you could even move the entire inactive list to the oldest gen
> instead of moving the folios one by one. Then you can avoid dealing
> with the reclaim argument entirely.
> 

However, since MGLRU distinguishes zones, we would have to move the folios one 
by one. So I've dropped this approach.

-- 
Best regards
Ridong