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,
kasong@tencent.com, shakeel.butt@linux.dev,
axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com,
david@kernel.org, rostedt@goodmis.org, mhiramat@kernel.org,
hannes@cmpxchg.org
Subject: Re: [PATCH v2 1/4] mm/mglru: add MM_WALK_EMPTY stats and tracepoint
Date: Tue, 1 Sep 2026 16:18:10 +0800 [thread overview]
Message-ID: <apaKQvME_y3K2bQx@fedora> (raw)
In-Reply-To: <CAGsJ_4x=sZcc0+wkAbS02YJUdpzxTTpozh7o7CSozWL=1K0rNw@mail.gmail.com>
On 09/01/26 at 03:11pm, Barry Song wrote:
> On Tue, Sep 1, 2026 at 2: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_ASSOCIATED - leaf entries whose folio is in this lruvec
> > MM_WALK_TOTAL - page-table walks completed
> > MM_WALK_EMPTY - walks that found no folio in this lruvec
> > MM_LEAF_EMPTY_WALKS - leaf entries scanned during empty walks
> >
> > 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>
> > ---
> [...]
> >
> > @@ -4109,8 +4113,28 @@ static bool try_to_inc_max_seq(struct lruvec *lruvec, unsigned long seq,
> >
> > do {
> > success = iterate_mm_list(walk, &mm);
> > - if (mm)
> > + if (mm) {
> > + bool empty = false;
> > +
> > walk_mm(mm, walk);
> > + /*
> > + * A walk that traversed page tables but found no folio
> > + * belonging to this lruvec (node+memcg) is pure waste.
> > + */
> > + if (walk->mm_stats[MM_LEAF_TOTAL]) {
> > + walk->mm_stats[MM_WALK_TOTAL]++;
> > + if (walk->mm_stats[MM_LEAF_ASSOCIATED] == 0) {
> > + walk->mm_stats[MM_WALK_EMPTY]++;
> > + walk->mm_stats[MM_LEAF_EMPTY_WALKS] +=
> > + walk->mm_stats[MM_LEAF_TOTAL];
> > + empty = true;
> > + }
> > + }
>
> Hi Baoquan,
>
> Where are we clearing these counters between different
> mms?
>
> It seems the previous mm_stats will affect the next mm
> if they aren't cleared.
No, they won't. The counters are cleared between mms. iterate_mm_list()
calls reset_mm_stats() from its "done:" path for every mm. reset_mm_stats()
accumulates walk->mm_stats into the per-hist mm_state->stats[hist] and
then zeroes walk->mm_stats[i].
>
>
> > + trace_mm_vmscan_lru_gen_walk(
> > + lruvec_pgdat(lruvec)->node_id, walk->seq,
> > + walk->mm_stats[MM_LEAF_TOTAL],
> > + walk->mm_stats[MM_LEAF_ASSOCIATED], empty);
> > + }
> > } while (mm);
> > done:
>
> Best Regards
> Barry
>
next prev parent reply other threads:[~2026-09-01 8:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 6:37 [PATCH v2 0/4] skip empty PUD subtrees during aging with a PUD-level Bloom filter Baoquan He
2026-09-01 6:37 ` [PATCH v2 1/4] mm/mglru: add MM_WALK_EMPTY stats and tracepoint Baoquan He
2026-09-01 7:11 ` Barry Song
2026-09-01 8:18 ` Baoquan He [this message]
2026-09-01 23:37 ` Barry Song
2026-09-01 6:37 ` [PATCH v2 2/4] mm/mglru: add PUD-level Bloom filter state and generic helpers Baoquan He
2026-09-01 6:37 ` [PATCH v2 3/4] mm/mglru: skip cold PUD subtrees during aging Baoquan He
2026-09-01 23:53 ` Barry Song
2026-09-02 2:29 ` Baoquan He
2026-09-02 3:22 ` Baoquan He
2026-09-04 3:41 ` Barry Song
2026-09-04 4:38 ` Baoquan He
2026-09-01 6:37 ` [PATCH v2 4/4] mm/mglru: count PUD subtrees skipped by the PUD-level filter 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=apaKQvME_y3K2bQx@fedora \
--to=baoquan.he@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.