linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: James Clark <james.clark@arm.com>
Cc: Leo Yan <leo.yan@linaro.org>,
	Ravi Bangoria <ravi.bangoria@amd.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] perf kmem: Support legacy tracepoints
Date: Mon, 9 Jan 2023 12:38:04 -0300	[thread overview]
Message-ID: <Y7w03A7f2zUWwihm@kernel.org> (raw)
In-Reply-To: <14dd06c2-39f8-ccb5-ce59-f3a1e45c94d0@arm.com>

Em Mon, Jan 09, 2023 at 03:11:47PM +0000, James Clark escreveu:
> 
> 
> On 08/01/2023 06:23, Leo Yan wrote:
> > Commit 11e9734bcb6a ("mm/slab_common: unify NUMA and UMA version of
> > tracepoints") removed tracepoints 'kmalloc_node' and
> > 'kmem_cache_alloc_node', these two tracepoints have disappeared in the
> > latest kernel, but we also need to consider the tool should be backward
> > compatible with old kernels.
> > 
> > If detects the tracepoint "kmem:kmalloc_node" is existed on a system,
> > this patch enables the legacy tracepoints, otherwise, it will ignore
> > them for the new kernels.
> > 
> > Reported-by: Ravi Bangoria <ravi.bangoria@amd.com>
> > Fixes: 11e9734bcb6a ("mm/slab_common: unify NUMA and UMA version of tracepoints")
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> >  tools/perf/builtin-kmem.c | 29 ++++++++++++++++++++++++++---
> >  1 file changed, 26 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
> > index e20656c431a4..50a3df5dc18a 100644
> > --- a/tools/perf/builtin-kmem.c
> > +++ b/tools/perf/builtin-kmem.c
> > @@ -1824,6 +1824,19 @@ static int parse_line_opt(const struct option *opt __maybe_unused,
> >  	return 0;
> >  }
> >  
> > +static bool slab_legacy_tp_is_exposed(void)
> > +{
> > +	/*
> > +	 * The tracepoints "kmem:kmalloc_node" and
> > +	 * "kmem:kmem_cache_alloc_node" have been removed on the latest
> > +	 * kernel, if the tracepoint "kmem:kmalloc_node" is existed it
> > +	 * means the tool is running on an old kernel, we need to
> > +	 * rollback to support these legacy tracepoints.
> > +	 */
> > +	return IS_ERR(trace_event__tp_format("kmem", "kmalloc_node")) ?
> > +		false : true;
> > +}
> > +
> >  static int __cmd_record(int argc, const char **argv)
> >  {
> >  	const char * const record_args[] = {
> > @@ -1831,22 +1844,28 @@ static int __cmd_record(int argc, const char **argv)
> >  	};
> >  	const char * const slab_events[] = {
> >  	"-e", "kmem:kmalloc",
> > -	"-e", "kmem:kmalloc_node",
> >  	"-e", "kmem:kfree",
> >  	"-e", "kmem:kmem_cache_alloc",
> > -	"-e", "kmem:kmem_cache_alloc_node",
> >  	"-e", "kmem:kmem_cache_free",
> >  	};
> > +	const char * const slab_legacy_events[] = {
> > +	"-e", "kmem:kmalloc_node",
> > +	"-e", "kmem:kmem_cache_alloc_node",
> > +	};
> 
> Reviewed-by: James Clark <james.clark@arm.com>
> 
> This fixes the error with mem:kmalloc_node for me.
> 
> I was thinking that it might be best to add all events to the list
> conditionally instead of just the legacy ones. That way, the same error
> won't happen in the future. But maybe it's best to have an explicit
> error again in case the breaking change was unintentional so it's fine
> as it is I think.

Just applied this, the changes you brains stormed may come as later
patches, thanks,

- Arnaldo

  reply	other threads:[~2023-01-09 15:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-08  6:23 [PATCH 1/2] perf kmem: Support legacy tracepoints Leo Yan
2023-01-08  6:24 ` [PATCH 2/2] perf kmem: Support field "node" in evsel__process_alloc_event() Leo Yan
2023-01-09 15:22   ` James Clark
2023-01-09 15:11 ` [PATCH 1/2] perf kmem: Support legacy tracepoints James Clark
2023-01-09 15:38   ` Arnaldo Carvalho de Melo [this message]
2023-01-10  1:45     ` Leo Yan
2023-01-10  9:33       ` James Clark

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=Y7w03A7f2zUWwihm@kernel.org \
    --to=acme@kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=vbabka@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).