From: Ridong Chen <ridong.chen@linux.dev>
To: Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
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-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-mm@kvack.org, Ridong Chen <ridong.chen@linux.dev>,
Ridong Chen <chenridong@xiaomi.com>
Subject: [PATCH RFC 0/2] mm/mglru: add tracepoints for aging and isolation
Date: Mon, 7 Sep 2026 12:24:45 +0800 [thread overview]
Message-ID: <20260907042447.2450663-1-ridong.chen@linux.dev> (raw)
From: Ridong Chen <chenridong@xiaomi.com>
MGLRU currently has no tracepoints of its own. The scan and evict paths
reuse the classic-LRU tracepoints (trace_mm_vmscan_lru_isolate() and
trace_mm_vmscan_lru_shrink_inactive()), which predate MGLRU and carry no
generation, sequence, memcg or swappiness context. A trace of a running
system therefore cannot tell which memcg a given scan/evict belongs to,
how far reclaim has progressed through the generations, or when a new
generation is created - so how MGLRU actually operates is effectively
invisible.
Add two tracepoints on the two paths that define an MGLRU cycle:
- mm_mglru_isolate_folios, on the isolation (eviction) path, carrying
the memcg id, the type scanned, the effective swappiness, the
scanned/isolated counts, and the anon/file min_seq and max_seq.
- mm_mglru_inc_max_seq, on the aging path, emitted when a new youngest
generation is created, carrying the memcg id, the new max_seq, and
the anon/file min_seq.
Both live at MGLRU-specific layers with no classic-LRU counterpart, so
they neither change nor duplicate the existing tracepoints. Paired, they
make the full aging-to-eviction window observable per memcg: aging
advances max_seq (the leading edge), isolation consumes the oldest
generations, and the min_seq/max_seq pair on each event shows how the
generation window moves over time.
A sample trace, with the classic-LRU tracepoints left enabled to show
how they interleave:
mm_mglru_inc_max_seq: memcg_id=1085 max_seq=7 anon_min_seq=4 file_min_seq=5
mm_vmscan_lru_isolate: classzone=4 order=0 nr_requested=17 nr_scanned=17 nr_skipped=0 nr_taken=0 lru=inactive_file
mm_vmscan_lru_isolate: classzone=4 order=0 nr_requested=17 nr_scanned=17 nr_skipped=0 nr_taken=0 lru=inactive_file
mm_mglru_isolate_folios: memcg_id=1085 type=file swappiness=0 nr_scanned=34 nr_isolated=0 anon_min_seq=4 file_min_seq=5 max_seq=7
mm_vmscan_lru_isolate: classzone=4 order=0 nr_requested=64 nr_scanned=64 nr_skipped=0 nr_taken=21 lru=inactive_file
mm_mglru_isolate_folios: memcg_id=73 type=file swappiness=0 nr_scanned=64 nr_isolated=21 anon_min_seq=7 file_min_seq=8 max_seq=10
mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=64 nr_reclaimed=21 nr_dirty=0 nr_writeback=0 nr_congested=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=0 nr_ref_keep=0 nr_unmap_fail=0 priority=4 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
mm_mglru_inc_max_seq: memcg_id=73 max_seq=11 anon_min_seq=8 file_min_seq=8
mm_vmscan_lru_isolate: classzone=4 order=0 nr_requested=64 nr_scanned=10 nr_skipped=0 nr_taken=10 lru=inactive_file
mm_mglru_isolate_folios: memcg_id=73 type=file swappiness=0 nr_scanned=10 nr_isolated=10 anon_min_seq=8 file_min_seq=8 max_seq=11
mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=10 nr_reclaimed=7 nr_dirty=0 nr_writeback=0 nr_congested=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=3 nr_ref_keep=0 nr_unmap_fail=0 priority=4 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
The two mm_mglru_isolate_folios lines tell memcg 1085 and memcg 73
apart, and show one making no progress (nr_isolated=0 against min_seq=4/5)
while the other evicts and then ages (max_seq 10 -> 11, min_seq catching
up to 8). The bare mm_vmscan_lru_isolate lines above carry none of that
context - they cannot even say which memcg they came from.
Sent as RFC to get feedback on the choice of tracepoint sites and fields
before proposing them as stable ABI.
Ridong Chen (2):
mm/mglru: add tracepoint for folio isolation
mm/mglru: add tracepoint for inc_max_seq
include/trace/events/vmscan.h | 77 +++++++++++++++++++++++++++++++++++
mm/vmscan.c | 13 +++++-
2 files changed, 89 insertions(+), 1 deletion(-)
--
2.34.1
next reply other threads:[~2026-09-07 4:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 4:24 Ridong Chen [this message]
2026-09-07 4:24 ` [PATCH RFC 1/2] mm/mglru: add tracepoint for folio isolation Ridong Chen
2026-09-09 6:40 ` Barry Song
2026-09-09 12:00 ` Ridong Chen
2026-09-09 12:11 ` Barry Song
2026-09-09 12:41 ` Ridong Chen
2026-09-07 4:24 ` [PATCH RFC 2/2] mm/mglru: add tracepoint for inc_max_seq Ridong Chen
2026-09-09 6:45 ` Barry Song
2026-09-09 12:43 ` Ridong Chen
2026-09-08 13:45 ` [PATCH RFC 0/2] mm/mglru: add tracepoints for aging and isolation Steven Rostedt
2026-09-09 11:37 ` Ridong Chen
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=20260907042447.2450663-1-ridong.chen@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=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@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