From: Michal Hocko <mhocko@suse.com>
To: Bixuan Cui <cuibixuan@vivo.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
akpm@linux-foundation.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org,
opensource.kernel@vivo.com
Subject: Re: [PATCH -next v6 0/2] Make memory reclamation measurable
Date: Wed, 21 Feb 2024 08:44:08 +0100 [thread overview]
Message-ID: <ZdWpyN_8Z6dvDQ48@tiehlicka> (raw)
In-Reply-To: <3d4f44ee-f533-446f-a9e6-7f58afc78d65@vivo.com>
On Wed 21-02-24 11:00:53, Bixuan Cui wrote:
>
>
> 在 2024/2/21 10:22, Steven Rostedt 写道:
> > It's up to the memory management folks to decide on this. -- Steve
> Noted with thanks.
It would be really helpful to have more details on why we need those
trace points.
It is my understanding that you would like to have a more fine grained
numbers for the time duration of different parts of the reclaim process.
I can imagine this could be useful in some cases but is it useful enough
and for a wider variety of workloads? Is that worth a dedicated static
tracepoints? Why an add-hoc dynamic tracepoints or BPF for a very
special situation is not sufficient?
In other words, tell us more about the usecases and why is this
generally useful.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-02-21 7:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 1:36 [PATCH -next v6 0/2] Make memory reclamation measurable Bixuan Cui
2024-01-05 1:36 ` [PATCH -next v6 1/2] mm: shrinker: add new event to trace shrink count Bixuan Cui
2024-01-05 1:36 ` [PATCH -next v6 2/2] mm: vmscan: add new event to trace shrink lru Bixuan Cui
2024-01-15 6:27 ` [PATCH -next v6 0/2] Make memory reclamation measurable Bixuan Cui
2024-01-24 2:41 ` Bixuan Cui
2024-02-21 1:44 ` Bixuan Cui
2024-02-21 2:22 ` Steven Rostedt
2024-02-21 3:00 ` Bixuan Cui
2024-02-21 7:44 ` Michal Hocko [this message]
2024-03-07 7:40 ` Bixuan Cui
2024-03-07 9:26 ` Michal Hocko
2024-03-08 8:37 ` Bixuan Cui
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=ZdWpyN_8Z6dvDQ48@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cuibixuan@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=opensource.kernel@vivo.com \
--cc=rostedt@goodmis.org \
/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.