Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ridong Chen <ridong.chen@linux.dev>
To: Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	David Hildenbrand <david@kernel.org>,
	Michal Hocko <mhocko@kernel.org>, Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	Steven Barrett <steven@liquorix.net>,
	"Jan Alexander Steffens (heftig)" <heftig@archlinux.org>,
	Yu Zhao <yuzhao@google.com>,
	Oleksandr Natalenko <oleksandr@natalenko.name>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Ridong Chen <chenridong@xiaomi.com>
Subject: Re: [PATCH] mm/mglru: preserve inactive placement when enabling MGLRU
Date: Fri, 21 Aug 2026 09:54:38 +0800	[thread overview]
Message-ID: <3fb795db-e7e9-415b-9a27-a99bdd34b090@linux.dev> (raw)
In-Reply-To: <CAGsJ_4wq46FkDQ_MhvEvtgdUQN5A_+_P+b6gbDvfEadus3WAaA@mail.gmail.com>



On 8/20/2026 3:50 PM, Barry Song wrote:
> On Thu, Aug 20, 2026 at 3:27 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.
>>
>> reclaiming also selects the insertion end in lru_gen_add_folio():
>> list_add_tail() for inactive folios, list_add() for active ones.  Both
>> the legacy LRU and a MGLRU generation keep the hottest folios at the
>> head and the coldest at the tail, and reclaim takes from the tail.  To
>> preserve that order the folio must be taken from the end matching the
>> insertion end, so take inactive folios from the head and active folios
>> from the tail; otherwise hot/cold would be reversed within the
>> generation.
>>
>> 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")
>> Suggested-by: Barry Song <baohua@kernel.org>
>> Assisted-by: Claude:claude-opus-4-8
>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
>> ---
>>   mm/vmscan.c | 29 +++++++++++++++++++++++++++--
>>   1 file changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 94fc4f25e99f..7be4cec9a838 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -5311,7 +5311,23 @@ static bool fill_evictable(struct lruvec *lruvec)
>>
>>                  while (!list_empty(head)) {
>>                          bool success;
>> -                       struct folio *folio = lru_to_folio(head);
>> +                       struct folio *folio;
>> +
>> +                       /*
>> +                        * Both the legacy LRU and a MGLRU generation keep the
>> +                        * hottest folios at the head and the coldest at the
>> +                        * tail, and reclaim takes from the tail.  To preserve
>> +                        * that order, the end we take from must match the end
>> +                        * lru_gen_add_folio() inserts at: inactive folios use
>> +                        * reclaiming=true (list_add_tail), so take from the
>> +                        * head; active folios use reclaiming=false (list_add),
>> +                        * so take from the tail.  Taking from the wrong end
>> +                        * would reverse hot/cold within the generation.
>> +                        */
> 
> too many words, maybe just:
> 
> lru_gen_add_folio() uses list_add_tail() rather than list_add()
> when reclaiming is true. Match its ordering to avoid cold/hot
> Inversion.
> 
>> +                       if (active)
>> +                               folio = lru_to_folio(head);
>> +                       else
>> +                               folio = list_first_entry(head, struct folio, lru);
>>
>>                          VM_WARN_ON_ONCE_FOLIO(folio_test_unevictable(folio), folio);
>>                          VM_WARN_ON_ONCE_FOLIO(folio_test_active(folio) != active, folio);
>> @@ -5319,7 +5335,16 @@ 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);
>> +                       /*
>> +                        * With reclaiming=false, lru_gen_folio_seq() would seed
>> +                        * an inactive folio near max_seq, which
>> +                        * lru_gen_is_active() reports as active, so its inactive
>> +                        * placement would be lost.  Pass reclaiming=!active to
>> +                        * seed it into the oldest generation instead.  This
>> +                        * reuses reclaiming beyond its folio_rotate_reclaimable()
>> +                        * meaning; it also picks list_add_tail() above.
>> +                        */
> 
> Maybe that's too verbose. How about:
> 
> "Borrow reclaiming=true to place inactive folios in the older gens"
> 
>> +                       success = lru_gen_add_folio(lruvec, folio, !active);
>>                          VM_WARN_ON_ONCE(!success);
>>
>>                          if (!--remaining)
> 
> This is admittedly a bit ugly, but it seems to be the simplest
> approach. Since switching MGLRU on and off is not a common scenario,
> we probably don't want to over-engineer it. So, with the above change:
> 
> Acked-by: Barry Song <baohua@kernel.org>

Thanks.

Will update.

-- 
Best regards
Ridong



      reply	other threads:[~2026-08-21  1:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20  7:26 [PATCH] mm/mglru: preserve inactive placement when enabling MGLRU Ridong Chen
2026-08-20  7:50 ` Barry Song
2026-08-21  1:54   ` Ridong Chen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3fb795db-e7e9-415b-9a27-a99bdd34b090@linux.dev \
    --to=ridong.chen@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=chenridong@xiaomi.com \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=heftig@archlinux.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=oleksandr@natalenko.name \
    --cc=qi.zheng@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=steven@liquorix.net \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox