[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4ba36631-ddf2-4944-8e7a-e048803955c7@linaro.org>
Date: Mon, 18 Nov 2024 10:18:01 +0000
From: James Clark <james.clark@...aro.org>
To: Ian Rogers <irogers@...gle.com>,
Linux perf Profiling <linux-perf-users@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>, Andi Kleen <ak@...ux.intel.com>,
Ahelenia ZiemiaĆska <nabijaczleweli@...ijaczleweli.xyz>,
Chen Ni <nichen@...as.ac.cn>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] Prefer evsel over evsel->core.idx
On 14/11/2024 11:07 pm, Ian Rogers wrote:
> James Clark's patches fixing evsel->core.idx [1] reminded me that we
> pass the int value around unnecessarily. Passing the evsel avoids
> issues if the evlist is reordered but paired with sanitizers we can
> also know when something is used when it shouldn't be. These patches
> do some initial work reducing the use of evsel->core.idx or reducing
> the API to pass evsels and not their interior index.
>
> [1] https://lore.kernel.org/lkml/20241114160450.295844-2-james.clark@linaro.org/
>
> Ian Rogers (3):
> perf stream: Use evsel rather than evsel->idx
> perf values: Use evsel rather than evsel->idx
> perf annotate: Prefer passing evsel to evsel->core.idx
>
> tools/perf/builtin-diff.c | 4 +-
> tools/perf/builtin-report.c | 4 +-
> tools/perf/builtin-top.c | 4 +-
> tools/perf/ui/browsers/annotate.c | 2 +-
> tools/perf/util/annotate.c | 32 +++++----
> tools/perf/util/annotate.h | 20 +++---
> tools/perf/util/stream.c | 7 +-
> tools/perf/util/stream.h | 10 +--
> tools/perf/util/values.c | 106 +++++++++++++-----------------
> tools/perf/util/values.h | 9 +--
> 10 files changed, 90 insertions(+), 108 deletions(-)
>
Reviewed-by: James Clark <james.clark@...aro.org>
Powered by blists - more mailing lists