From: "Hui Zhu" <hui.zhu@linux.dev>
To: 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>, Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Hui Zhu <zhuhui@kylinos.cn>, Baolin Wang <baolin.wang@linux.alibaba.com>
Subject: [PATCH v2] mm/mglru: Fix young counter undercount for large folios
Date: Thu, 13 Aug 2026 14:10:19 +0800 [thread overview]
Message-ID: <20260813061019.49806-1-hui.zhu@linux.dev> (raw)
From: Hui Zhu <zhuhui@kylinos.cn>
lru_gen_look_around() feeds its local 'young' counter into
suitable_to_scan(), which decides whether the current PMD is added to
the bloom filter and checked again on the next aging round.
The folio triggering the look-around is processed at function entry:
test_and_clear_young_ptes_notify() clears the accessed bits of the nr
PTEs it maps, and the function bails out if none of them is young. The
loop that follows therefore never recounts this folio, since its
accessed bits are already cleared. Every other young folio the loop
finds is accounted as a batch (young += nr), where nr is the number of
consecutive PTEs it maps. The triggering folio, however, still
contributes a fixed young = 1 regardless of its size -- a leftover from
before PTE batching. A large triggering folio is thus accounted
inconsistently with the rest of the window.
Initialize young to nr so the triggering folio is accounted the same way
as any other young folio batch in the loop.
Note this is a deliberate overestimate, not a measured value. The
test-and-clear helper only reports whether any of the nr PTEs is young,
not how many were accessed, so the true number of accessed PTEs in a
large folio is unknown and can be smaller than nr. Counting the full
batch is intentional: the mm core tracks accessed/dirty state per folio,
not per page, so a per-page count is neither obtainable nor meaningful.
The only consumer is suitable_to_scan(), and the bloom filter it feeds
tolerates error. Overestimating is also the safe direction: at worst a
PMD that saw little access is rescanned, whereas underestimating could
skip rescanning a PMD whose folios are still hot and reclaim them
incorrectly. (nr here is the PTE batch size, not necessarily
folio_nr_pages().)
Fixes: 56e5b60b2114 ("mm: support batched checking of the young flag for MGLRU")
Signed-off-by: Hui Zhu <zhuhui@kylinos.cn>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
Changelog:
v2:
According to the comments of Baolin and Barry, update git commit log.
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bc324e37c5f1..264017850a55 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4192,7 +4192,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
unsigned long end;
struct lru_gen_mm_walk *walk;
struct folio *last = NULL;
- int young = 1;
+ int young = nr;
pte_t *pte = pvmw->pte;
unsigned long addr = pvmw->address;
struct vm_area_struct *vma = pvmw->vma;
--
2.53.0
next reply other threads:[~2026-08-13 6:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 6:10 Hui Zhu [this message]
2026-08-13 6:35 ` [PATCH v2] mm/mglru: Fix young counter undercount for large folios Barry Song
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=20260813061019.49806-1-hui.zhu@linux.dev \
--to=hui.zhu@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.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=qi.zheng@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhuhui@kylinos.cn \
/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