From: Shakeel Butt <shakeel.butt@linux.dev>
To: SUVONOV BUNYOD <b.suvonov@sjtu.edu.cn>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org,
rostedt@goodmis.org, mhiramat@kernel.org, david@kernel.org,
mhocko@kernel.org, zhengqi arch <zhengqi.arch@bytedance.com>,
ljs@kernel.org,
mathieu desnoyers <mathieu.desnoyers@efficios.com>,
linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmscan: add balance_pgdat begin/end tracepoints
Date: Thu, 23 Apr 2026 19:15:59 -0700 [thread overview]
Message-ID: <aerSNntuPLdGWts6@linux.dev> (raw)
In-Reply-To: <1868971658.1970916.1776991584726.JavaMail.zimbra@sjtu.edu.cn>
On Fri, Apr 24, 2026 at 08:46:24AM +0800, SUVONOV BUNYOD wrote:
> Thank you for reviewing Shakeel,
>
> > Do we need to trace highest_zoneidx at the end? Can it change within
> > balance_pgdat()?
>
> highest_zoneidx does not change within a balance_pgdat() invocation. It
> is passed in as an argument and remains the classzone bound used for the
> balancing checks throughout the function.
>
> I kept highest_zoneidx in the end tracepoint to make the outcome event
> self-contained. In principle, begin/end correlation is possible, but
> under sustained memory pressure kswapd reclaim can be frequent enough
> that consumers may prefer to analyze end events directly, and any
> dependence on matching begin/end becomes less convenient and less robust
> in the presence of filtering or dropped trace records.
>
> Since nr_reclaimed and the final order are only known at the end, having
> highest_zoneidx there allows end-only analysis without correlating with
> the begin event.
>
> For example, it lets users answer questions like:
> - this pass reclaimed too much or too little memory; what highest_zoneidx
> did that result correspond to?
> - how much reclaim was done when balancing up to ZONE_NORMAL vs other
> classzone bounds?
> - when highest_zoneidx == ZONE_NORMAL, how often did reclaim finish at
> order=0?
>
> So it is there because it provides context for the end-of-reclaim result.
> Do you think this is sufficient justification? If not, then I can drop it
> from the end tracepoint in v2.
I think it is ok but let's add this reasoning in the commit message.
next prev parent reply other threads:[~2026-04-24 2:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 10:37 [PATCH] mm/vmscan: add balance_pgdat begin/end tracepoints Bunyod Suvonov
2026-04-23 17:46 ` Shakeel Butt
2026-04-24 0:46 ` SUVONOV BUNYOD
2026-04-24 2:15 ` Shakeel Butt [this message]
2026-04-24 3:14 ` [PATCH v2] " Bunyod Suvonov
2026-04-24 3:16 ` Shakeel Butt
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=aerSNntuPLdGWts6@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=b.suvonov@sjtu.edu.cn \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--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=rostedt@goodmis.org \
--cc=zhengqi.arch@bytedance.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.