[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y7zC5imskN9tvtBn@leoy-yangtze.lan>
Date: Tue, 10 Jan 2023 09:45:11 +0800
From: Leo Yan <leo.yan@...aro.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: James Clark <james.clark@....com>,
Ravi Bangoria <ravi.bangoria@....com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Vlastimil Babka <vbabka@...e.cz>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] perf kmem: Support legacy tracepoints
On Mon, Jan 09, 2023 at 12:38:04PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > > + const char * const slab_legacy_events[] = {
> > > + "-e", "kmem:kmalloc_node",
> > > + "-e", "kmem:kmem_cache_alloc_node",
> > > + };
> >
> > Reviewed-by: James Clark <james.clark@....com>
> >
> > This fixes the error with mem:kmalloc_node for me.
Thanks for reviewing and testing!
> > 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.
Yeah, this is a good idea for refactoring.
James, do you mind to send patches for this?
> Just applied this, the changes you brains stormed may come as later
> patches, thanks,
Thanks, Arnaldo.
Leo
Powered by blists - more mailing lists