From: Dmitry Rokosov <ddrokosov@salutedevices.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: <rostedt@goodmis.org>, <mhiramat@kernel.org>,
<hannes@cmpxchg.org>, <mhocko@kernel.org>,
<roman.gushchin@linux.dev>, <muchun.song@linux.dev>,
<akpm@linux-foundation.org>, <kernel@sberdevices.ru>,
<rockosov@gmail.com>, <cgroups@vger.kernel.org>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<bpf@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] mm: memcg: print out cgroup name in the memcg tracepoints
Date: Thu, 23 Nov 2023 11:03:34 +0300 [thread overview]
Message-ID: <20231123080334.5owfpg7zl4nzeh4t@CAB-WSD-L081021> (raw)
In-Reply-To: <20231123072126.jpukmc6rqmzckdw2@google.com>
Hello Shakeel,
Thank you for quick review!
Please find my thoughts below.
On Thu, Nov 23, 2023 at 07:21:26AM +0000, Shakeel Butt wrote:
> On Wed, Nov 22, 2023 at 01:01:55PM +0300, Dmitry Rokosov wrote:
> > Sometimes it is necessary to understand in which memcg tracepoint event
> > occurred. The function cgroup_name() is a useful tool for this purpose.
> > To integrate cgroup_name() into the existing memcg tracepoints, this
> > patch introduces a new tracepoint template for the begin() and end()
> > events, utilizing static __array() to store the cgroup name.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > include/trace/events/vmscan.h | 77 +++++++++++++++++++++++++++++------
> > mm/vmscan.c | 10 ++---
> > 2 files changed, 70 insertions(+), 17 deletions(-)
> >
> > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
> > index d2123dd960d5..9b49cd120ae9 100644
> > --- a/include/trace/events/vmscan.h
> > +++ b/include/trace/events/vmscan.h
> > @@ -141,19 +141,47 @@ DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template, mm_vmscan_direct_reclaim_b
> > );
> >
> > #ifdef CONFIG_MEMCG
> > -DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template, mm_vmscan_memcg_reclaim_begin,
> >
> > - TP_PROTO(int order, gfp_t gfp_flags),
> > +DECLARE_EVENT_CLASS(mm_vmscan_memcg_reclaim_begin_template,
> >
> > - TP_ARGS(order, gfp_flags)
> > + TP_PROTO(int order, gfp_t gfp_flags, const struct mem_cgroup *memcg),
> > +
> > + TP_ARGS(order, gfp_flags, memcg),
> > +
> > + TP_STRUCT__entry(
> > + __field(int, order)
> > + __field(unsigned long, gfp_flags)
> > + __array(char, name, NAME_MAX + 1)
> > + ),
> > +
> > + TP_fast_assign(
> > + __entry->order = order;
> > + __entry->gfp_flags = (__force unsigned long)gfp_flags;
> > + cgroup_name(memcg->css.cgroup,
> > + __entry->name,
> > + sizeof(__entry->name));
>
> Any reason not to use cgroup_ino? cgroup_name may conflict and be
> ambiguous.
I actually didn't consider it, as the cgroup name serves as a clear tag
for filtering the appropriate cgroup in the entire trace file. However,
you are correct that there might be conflicts with cgroup names.
Therefore, it might be better to display both tags: ino and name. What
do you think on this?
--
Thank you,
Dmitry
next prev parent reply other threads:[~2023-11-23 8:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 10:01 [PATCH v2 0/2] mm: memcg: improve vmscan tracepoints Dmitry Rokosov
2023-11-22 10:01 ` [PATCH v2 1/2] mm: memcg: print out cgroup name in the memcg tracepoints Dmitry Rokosov
2023-11-23 7:21 ` Shakeel Butt
2023-11-23 8:03 ` Dmitry Rokosov [this message]
2023-11-23 8:15 ` Shakeel Butt
2023-11-23 8:45 ` Dmitry Rokosov
2023-11-23 11:21 ` Dmitry Rokosov
[not found] ` <20231122100156.6568-3-ddrokosov@salutedevices.com>
2023-11-22 10:23 ` [PATCH v2 2/2] mm: memcg: introduce new event to trace shrink_memcg Michal Hocko
2023-11-22 10:58 ` Dmitry Rokosov
2023-11-22 13:24 ` Michal Hocko
2023-11-22 18:57 ` Dmitry Rokosov
2023-11-23 11:26 ` Dmitry Rokosov
2023-11-27 9:25 ` Michal Hocko
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=20231123080334.5owfpg7zl4nzeh4t@CAB-WSD-L081021 \
--to=ddrokosov@salutedevices.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel@sberdevices.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhiramat@kernel.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=rockosov@gmail.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=shakeelb@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