From: Baoquan He <baoquan.he@linux.dev>
To: Barry Song <baohua@kernel.org>
Cc: Baoquan He <hebaoquan@kylinos.cn>,
linux-mm@kvack.org, akpm@linux-foundation.org, david@kernel.org,
rostedt@goodmis.org, mhiramat@kernel.org, kasong@tencent.com,
qi.zheng@linux.dev, shakeel.butt@linux.dev,
axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com,
baolin.wang@linux.alibaba.com, hannes@cmpxchg.org
Subject: Re: [PATCH 1/9] mm/mglru: add MM_WALK_EMPTY stats and tracepoint
Date: Mon, 31 Aug 2026 16:17:56 +0800 [thread overview]
Message-ID: <apU4tEOSo4aR-O_q@fedora> (raw)
In-Reply-To: <apE87WYTYvfAqXbc@fedora>
On 08/28/26 at 03:46pm, Baoquan He wrote:
> On 08/28/26 at 01:37pm, Barry Song wrote:
> > On Mon, Aug 24, 2026 at 3:38 PM Baoquan He <hebaoquan@kylinos.cn> wrote:
> > >
> > > Add per-walk counters to measure empty aging walks which traverse
> > > an mm's page tables but find no folio for the current lruvec (node+memcg).
> > > These are common on multi-NUMA node systems because lru_gen_use_mm() marks
> > > an mm for all nodes at every context switch.
> > >
> > > New counters (accumulated in mm_state->stats[]):
> > >
> > > MM_LEAF_ELIGIBLE - folios belonging to this lruvec
> > > MM_WALK_TOTAL - page-table walks completed
> > > MM_WALK_EMPTY - walks that found no eligible folio
> > > MM_LEAF_TOTAL_EMPTY - leaf entries scanned by empty walks
> >
> > Hi Baoquan,
> >
> > I'm having a hard time understanding what MM_LEAF_ELIGIBLE means.
> > In particular, I'm not sure why "eligible" refers to folios here.
> >
> > I'm also finding MM_LEAF_TOTAL_EMPTY quite difficult to understand
> > without looking at the implementation.
> >
> > Could we come up with clearer and more descriptive names for these
> > counters? might be?
> >
> > MM_LEAF_ASSOCIATED, /* folios associated with this lruvec */
> > MM_WALK_TOTAL, /* completed page-table walks */
> > MM_WALK_WITHOUT_ASSOCIATED, /* walks with no associated folio */
> > MM_LEAF_WITHOUT_ASSOCIATED, /* leaf entries in such walks */
Hi Barry,
Thanks for the naming suggestions — they helped, and I've incorporated
most of them in v2. Here's how each counter ended up:
1. MM_LEAF_ELIGIBLE -> MM_LEAF_ASSOCIATED:
- agreed, "eligible" was a bad choice since it normally implies reclaim
eligibility in this context. Adopted your suggestion.
2. MM_WALK_EMPTY:
- I kept this one rather than MM_WALK_WITHOUT_ASSOCIATED. Two reasons:
- (a) "empty walk" is exactly the concept this series is about,
suppressing/reducing empty page table walks, so the name ties directly
to the motivation;
(b) "a walk without associated [folios]" reads a bit weird. The walk
itself isn't associated with anything, the folios in its page tables
are. The comment now is changed as "walks that found no folio in this
lruvec".
3. MM_LEAF_TOTAL_EMPTY -> MM_LEAF_EMPTY_WALKS:
- I will go with this instead of MM_LEAF_WITHOUT_ASSOCIATED.
The latter sounds like "leaf entries that have no associated folio",
which is confusing: those leaf entries do have folios, they're just
associated with a different lruvec (node+memcg). What's empty is the
walk, not the leaves. MM_LEAF_EMPTY_WALKS ("leaf entries scanned during
empty walks") is parallel to MM_WALK_EMPTY and can't be misread.
All four counters and the tracepoint field are updated accordingly.
Please check if they are OK to you.
Thanks
Baoquan
> >
> > >
> > > A new tracepoint, mm_vmscan_lru_gen_walk(), fires after each walk, and the
> > > debugfs lru_gen output ("TYFALWEE") exposes the new counters.
> > >
> > > Signed-off-by: Baoquan He <hebaoquan@kylinos.cn>
> > > ---
> > > include/linux/mmzone.h | 4 ++++
> > > include/trace/events/vmscan.h | 28 ++++++++++++++++++++++++++++
> > > mm/vmscan.c | 30 ++++++++++++++++++++++++++----
> > > 3 files changed, 58 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > > index 94f9c3ff5416..229d27fbfb54 100644
> > > --- a/include/linux/mmzone.h
> > > +++ b/include/linux/mmzone.h
> > > @@ -595,6 +595,10 @@ enum {
> > > MM_LEAF_YOUNG, /* young leaf entries */
> > > MM_NONLEAF_FOUND, /* non-leaf entries found in Bloom filters */
> > > MM_NONLEAF_ADDED, /* non-leaf entries added to Bloom filters */
> > > + MM_LEAF_ELIGIBLE, /* folios belonging to this lruvec (node+memcg) */
> > > + MM_WALK_TOTAL, /* page-table walks completed */
> > > + MM_WALK_EMPTY, /* walks that found no eligible folio */
> > > + MM_LEAF_TOTAL_EMPTY, /* leaf entries scanned by empty walks */
> > > NR_MM_STATS
> > > };
> > >
> >
> > Best Regards
> > Barry
> >
next prev parent reply other threads:[~2026-08-31 8:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 7:37 [PATCH 0/9] mm/mglru: suppress empty page table walks during aging Baoquan He
2026-08-24 7:37 ` [PATCH 1/9] mm/mglru: add MM_WALK_EMPTY stats and tracepoint Baoquan He
2026-08-28 5:37 ` Barry Song
2026-08-28 7:46 ` Baoquan He
2026-08-31 8:17 ` Baoquan He [this message]
2026-08-24 7:37 ` [PATCH 2/9] mm/mglru: suppress cross-node empty page table walks Baoquan He
2026-08-28 6:35 ` Barry Song
2026-08-28 7:26 ` Baoquan He
2026-08-24 7:38 ` [PATCH 3/9] mm/mglru: add debugfs knob for the empty-walk skip threshold Baoquan He
2026-08-24 7:38 ` [PATCH 4/9] mm/mglru: invalidate empty-walk skip on page fault and migration Baoquan He
2026-08-24 7:38 ` [PATCH 5/9] mm/mglru: add PUD-level Bloom filter state Baoquan He
2026-08-24 7:38 ` [PATCH 6/9] mm/mglru: refactor Bloom filter helpers for two filter levels Baoquan He
2026-08-24 7:38 ` [PATCH 7/9] mm/mglru: skip PUD subtrees during aging Baoquan He
2026-08-24 7:38 ` [PATCH 8/9] mm/mglru: report hot PUDs from the rmap feedback path Baoquan He
2026-08-24 7:38 ` [PATCH 9/9] mm/mglru: count PUD subtrees skipped by the PUD-level filter Baoquan He
2026-08-24 8:11 ` [PATCH 0/9] mm/mglru: suppress empty page table walks during aging Baoquan He
2026-08-24 8:42 ` Baoquan He
2026-08-28 6:11 ` Barry Song
2026-08-28 7:42 ` Baoquan He
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=apU4tEOSo4aR-O_q@fedora \
--to=baoquan.he@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=hebaoquan@kylinos.cn \
--cc=kasong@tencent.com \
--cc=linux-mm@kvack.org \
--cc=mhiramat@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rostedt@goodmis.org \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--cc=yuanchu@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