From: Ridong Chen <ridong.chen@linux.dev>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Baoquan He <baoquan.he@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
"open list:MEMORY MANAGEMENT - MGLRU (MULTI-GEN LRU)"
<linux-mm@kvack.org>, Ridong Chen <chenridong@xiaomi.com>
Subject: Re: [PATCH 2/3] mm/mglru: add tracepoint for scan_folios()
Date: Sun, 13 Sep 2026 18:25:38 +0800 [thread overview]
Message-ID: <cec74135-b7c6-4405-8e0e-d33564429121@linux.dev> (raw)
In-Reply-To: <20260911101120.25e3495a@gandalf.local.home>
On 9/11/2026 10:11 PM, Steven Rostedt wrote:
> On Fri, 11 Sep 2026 15:28:47 +0800
> Ridong Chen <ridong.chen@linux.dev> wrote:
>
>> diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
>> index 8a872990b4be..c39dfacef033 100644
>> --- a/include/trace/events/vmscan.h
>> +++ b/include/trace/events/vmscan.h
>> @@ -392,6 +392,69 @@ TRACE_EVENT(mm_vmscan_lru_isolate,
>> __print_symbolic(__entry->lru, LRU_NAMES))
>> );
>>
>> +TRACE_EVENT(mm_mglru_scan_folios,
>> +
>> + TP_PROTO(u64 memcg_id,
>> + int highest_zoneidx,
>> + int order,
>> + unsigned long nr_requested,
>> + unsigned long nr_scanned,
>> + unsigned long nr_sorted,
>> + unsigned long nr_skipped,
>> + unsigned long nr_taken,
>> + int lru,
>> + unsigned long max_seq,
>> + int tier,
>> + unsigned long min_seq),
>> +
>> + TP_ARGS(memcg_id, highest_zoneidx, order, nr_requested, nr_scanned,
>> + nr_sorted, nr_skipped, nr_taken, lru, max_seq, tier, min_seq),
>> +
>> + TP_STRUCT__entry(
>> + __field(u64, memcg_id)
>> + __field(int, highest_zoneidx)
>> + __field(int, order)
>> + __field(unsigned long, nr_requested)
>> + __field(unsigned long, nr_scanned)
>> + __field(unsigned long, nr_sorted)
>> + __field(unsigned long, nr_skipped)
>> + __field(unsigned long, nr_taken)
>> + __field(int, lru)
>> + __field(unsigned long, max_seq)
>> + __field(int, tier)
>> + __field(unsigned long, min_seq)
>
Thank you very much for your review.
> Please keep "int"s together. This creates a structure that is used to write
> into the ring buffer. On 64bit machines, the above would add 4 bytes of
> padding after each int, whereas:
>
> __field(unsigned long, max_seq)
> __field(unsigned long, min_seq)
> __field(int, lru)
> __field(int, tier)
>
>
> would not.
>
Will upate.
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->memcg_id = memcg_id;
>> + __entry->highest_zoneidx = highest_zoneidx;
>> + __entry->order = order;
>> + __entry->nr_requested = nr_requested;
>> + __entry->nr_scanned = nr_scanned;
>> + __entry->nr_sorted = nr_sorted;
>> + __entry->nr_skipped = nr_skipped;
>> + __entry->nr_taken = nr_taken;
>> + __entry->lru = lru;
>> + __entry->max_seq = max_seq;
>> + __entry->tier = tier;
>> + __entry->min_seq = min_seq;
>> + ),
>> +
>> + TP_printk("memcg_id=%llu classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_sorted=%lu nr_skipped=%lu nr_taken=%lu lru=%s max_seq=%lu tier=%d min_seq=%lu",
>> + __entry->memcg_id,
>> + __entry->highest_zoneidx,
>> + __entry->order,
>> + __entry->nr_requested,
>> + __entry->nr_scanned,
>> + __entry->nr_sorted,
>> + __entry->nr_skipped,
>> + __entry->nr_taken,
>> + __print_symbolic(__entry->lru, LRU_NAMES),
>> + __entry->max_seq,
>> + __entry->tier,
>> + __entry->min_seq)
>> +);
>> +
>> TRACE_EVENT(mm_vmscan_write_folio,
>>
>> TP_PROTO(struct folio *folio),
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 2554a6513aa8..bd1b9ecf2e84 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -4876,6 +4876,12 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
>> trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan,
>> scanned, skipped, isolated,
>> type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON);
>> + trace_mm_mglru_scan_folios(mem_cgroup_id(lruvec_memcg(lruvec)),
>> + sc->reclaim_idx, sc->order, nr_to_scan,
>> + scanned, sorted, skipped, isolated,
>> + type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON,
>> + lrugen->max_seq, tier,
>> + lrugen->min_seq[type]);
>
> Can't this information be processed in the tracepoint? That is:
>
> TP_PROTO(struct lruvec *lruvec,
> struct scan_control *sc,
> struct lru_gen_folio *lrugen,
> unsigned long nr_requested,
> unsigned long nr_scanned,
> unsigned long nr_sorted,
> unsigned long nr_skipped,
> unsigned long nr_taken,
> int type),
>
> TP_ARGS(lruvec, sc, lrugen, nr_requested, nr_scanned,
> nr_sorted, nr_skipped, nr_taken, type),
>
> TP_STRUCT__entry(
> __field(u64, memcg_id)
> __field(int, highest_zoneidx)
> __field(int, order)
> __field(unsigned long, nr_requested)
> __field(unsigned long, nr_scanned)
> __field(unsigned long, nr_sorted)
> __field(unsigned long, nr_skipped)
> __field(unsigned long, nr_taken)
> __field(unsigned long, max_seq)
> __field(unsigned long, min_seq)
> __field(int, lru)
> __field(int, tier)
> ),
>
> TP_fast_assign(
> __entry->memcg_id = mem_cgroup_id(lruvec_memcg(lruvec));
> __entry->highest_zoneidx = sc->reclaim_idx;
> __entry->order = sc->order;
> __entry->nr_requested = nr_requested;
> __entry->nr_scanned = nr_scanned;
> __entry->nr_sorted = nr_sorted;
> __entry->nr_skipped = nr_skipped;
> __entry->nr_taken = nr_taken;
> __entry->lru = type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON;
> __entry->max_seq = lrugen->max_seq;
> __entry->tier = tier;
> __entry->min_seq = lrugen->min_seq;
> ),
>
>
> This moves the code to generate the parameters into the TP_fast_assign()
> which is in a separate text section. It remove code from the work flow
> improving instruction cache.
>
> Same can be done for that trace_mm_vmscan_lru_isolate() trace event.
>
Sashiko has reported the same issue, so I updated my series [1] when I received
Sashiko's report. Thank you again for pointing this out.
[1] https://lore.kernel.org/linux-mm/20260911102939.2485750-3-ridong.chen@linux.dev/
>
>>
>> *isolatedp = isolated;
>> return scanned;
>> --
--
Best regards
Ridong
next prev parent reply other threads:[~2026-09-13 10:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 7:28 [PATCH 0/3] mm/mglru: add tracepoints for scan and aging paths Ridong Chen
2026-09-11 7:28 ` [PATCH 1/3] mm/mglru: factor out lru_gen_seq_nr_pages() Ridong Chen
2026-09-11 7:28 ` [PATCH 2/3] mm/mglru: add tracepoint for scan_folios() Ridong Chen
2026-09-11 7:42 ` sashiko-bot
2026-09-11 10:04 ` Ridong Chen
2026-09-11 14:11 ` Steven Rostedt
2026-09-13 10:25 ` Ridong Chen [this message]
2026-09-11 7:28 ` [PATCH 3/3] mm/mglru: add tracepoint for inc_max_seq() Ridong Chen
2026-09-11 14:15 ` Steven Rostedt
2026-09-13 10:28 ` 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=cec74135-b7c6-4405-8e0e-d33564429121@linux.dev \
--to=ridong.chen@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--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 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.