From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
James Clark <james.clark@linaro.org>,
Ze Gao <zegao2021@gmail.com>, Weilin Wang <weilin.wang@intel.com>,
Dominique Martinet <asmadeus@codewreck.org>,
Jean-Philippe Romain <jean-philippe.romain@foss.st.com>,
Junhao He <hejunhao3@huawei.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
Subject: Re: [PATCH v5 0/4] Prefer sysfs/JSON events also when no PMU is provided
Date: Wed, 29 Jan 2025 14:05:17 -0800 [thread overview]
Message-ID: <Z5qmHaHRtWKnG4vT@google.com> (raw)
In-Reply-To: <20250109222109.567031-1-irogers@google.com>
On Thu, Jan 09, 2025 at 02:21:05PM -0800, Ian Rogers wrote:
> At the RISC-V summit the topic of avoiding event data being in the
> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON
> events being the priority when no PMU is provided so that legacy
> events maybe supported via json. Originally Mark Rutland also
> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple
> M? processors, but James Clark more recently tested this and believes
> the driver issues there may not have existed or have been resolved. In
> any case, it is inconsistent that with a PMU event names avoid legacy
> encodings, but when wildcarding PMUs (ie without a PMU with the event
> name) the legacy encodings have priority.
>
> The patch doing this work was reverted in a v6.10 release candidate
> as, even though the patch was posted for weeks and had been on
> linux-next for weeks without issue, Linus was in the habit of using
> explicit legacy events with unsupported precision options on his
> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles
> where ARM decided to call the events bus_cycles and cycles, the latter
> being also a legacy event name. ARM haven't renamed the cycles event
> to a more consistent cpu_cycles and avoided the problem. With these
> changes the problematic event will now be skipped, a large warning
> produced, and perf record will continue for the other PMU events. This
> solution was proposed by Arnaldo.
>
> Two minor changes have been added to help with the error message and
> to work around issues occurring with "perf stat metrics (shadow stat)
> test".
>
> The patches have only been tested on my x86 non-hybrid laptop.
>
> v5: Follow Namhyung's suggestion and ignore the case where command
> line dummy events fail to open alongside other events that all
> fail to open. Note, the Tested-by tags are left on the series as
> v4 and v5 were changing an error case that doesn't occur in
> testing but was manually tested by myself.
>
> v4: Rework the no events opening change from v3 to make it handle
> multiple dummy events. Sadly an evlist isn't empty if it just
> contains dummy events as the dummy event may be used with "perf
> record -e dummy .." as a way to determine whether permission
> issues exist. Other software events like cpu-clock would suffice
> for this, but the using dummy genie has left the bottle.
>
> Another problem is that we appear to have an excessive number of
> dummy events added, for example, we can likely avoid a dummy event
> and add sideband data to the original event. For auxtrace more
> dummy events may be opened too. Anyway, this has led to the
> approach taken in patch 3 where the number of dummy parsed events
> is computed. If the number of removed/failing-to-open non-dummy
> events matches the number of non-dummy events then we want to
> fail, but only if there are no parsed dummy events or if there was
> one then it must have opened. The math here is hard to read, but
> passes my manual testing.
>
> v3: Make no events opening for perf record a failure as suggested by
> James Clark and Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>. Also,
> rebase.
>
> v2: Rebase and add tested-by tags from James Clark, Leo Yan and Atish
> Patra who have tested on RISC-V and ARM CPUs, including the
> problem case from before.
>
> Ian Rogers (4):
> perf evsel: Add pmu_name helper
> perf stat: Fix find_stat for mixed legacy/non-legacy events
I think the first two are quite independent. I'll take them first.
Thanks,
Namhyung
> perf record: Skip don't fail for events that don't open
> perf parse-events: Reapply "Prefer sysfs/JSON hardware events over
> legacy"
>
> tools/perf/builtin-record.c | 47 ++++++++++++++++++---
> tools/perf/util/evsel.c | 10 +++++
> tools/perf/util/evsel.h | 1 +
> tools/perf/util/parse-events.c | 26 +++++++++---
> tools/perf/util/parse-events.l | 76 +++++++++++++++++-----------------
> tools/perf/util/parse-events.y | 60 ++++++++++++++++++---------
> tools/perf/util/pmus.c | 20 +++++++--
> tools/perf/util/stat-shadow.c | 3 +-
> 8 files changed, 169 insertions(+), 74 deletions(-)
>
> --
> 2.47.1.613.gc27f4b7a9f-goog
>
next prev parent reply other threads:[~2025-01-29 22:05 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 22:21 [PATCH v5 0/4] Prefer sysfs/JSON events also when no PMU is provided Ian Rogers
2025-01-09 22:21 ` [PATCH v5 1/4] perf evsel: Add pmu_name helper Ian Rogers
2025-01-09 22:21 ` [PATCH v5 2/4] perf stat: Fix find_stat for mixed legacy/non-legacy events Ian Rogers
2025-01-09 22:21 ` [PATCH v5 3/4] perf record: Skip don't fail for events that don't open Ian Rogers
2025-01-10 1:25 ` Namhyung Kim
2025-01-10 4:44 ` Ian Rogers
2025-01-10 18:55 ` Namhyung Kim
2025-01-10 19:18 ` Ian Rogers
2025-01-14 19:29 ` Namhyung Kim
2025-01-14 23:55 ` Ian Rogers
2025-01-15 22:14 ` Namhyung Kim
2025-01-15 22:40 ` Ian Rogers
2025-01-10 14:18 ` Arnaldo Carvalho de Melo
2025-01-10 16:42 ` Ian Rogers
2025-01-10 19:26 ` Namhyung Kim
2025-01-10 21:33 ` Ian Rogers
2025-01-13 20:51 ` Namhyung Kim
2025-01-13 23:04 ` Ian Rogers
2025-01-15 17:31 ` Namhyung Kim
2025-01-15 17:56 ` Ian Rogers
2025-01-29 21:24 ` Namhyung Kim
2025-01-09 22:21 ` [PATCH v5 4/4] perf parse-events: Reapply "Prefer sysfs/JSON hardware events over legacy" Ian Rogers
2025-01-10 19:40 ` Namhyung Kim
2025-01-10 19:52 ` Atish Kumar Patra
2025-01-13 20:56 ` Namhyung Kim
2025-01-10 22:15 ` Ian Rogers
2025-01-13 22:01 ` Namhyung Kim
2025-01-13 22:51 ` Ian Rogers
2025-01-14 2:31 ` Ian Rogers
2025-01-15 17:59 ` Namhyung Kim
2025-01-15 21:20 ` Ian Rogers
2025-01-29 21:55 ` Namhyung Kim
2025-01-30 1:16 ` Ian Rogers
2025-01-30 5:16 ` Namhyung Kim
2025-01-30 6:03 ` Ian Rogers
2025-01-31 22:28 ` Namhyung Kim
2025-01-30 6:12 ` Atish Kumar Patra
2025-01-31 22:42 ` Namhyung Kim
2025-02-01 8:45 ` Ian Rogers
2025-02-04 0:15 ` Namhyung Kim
2025-02-04 0:41 ` Ian Rogers
2025-02-05 1:57 ` Namhyung Kim
2025-02-05 4:48 ` Ian Rogers
2025-02-06 5:09 ` Namhyung Kim
2025-02-06 7:44 ` Ian Rogers
2025-02-07 4:44 ` Namhyung Kim
2025-02-07 6:15 ` Ian Rogers
2025-02-07 17:18 ` Atish Kumar Patra
2025-02-19 23:22 ` Namhyung Kim
2025-02-19 23:32 ` Ian Rogers
2025-02-03 5:47 ` Atish Kumar Patra
2025-01-29 22:05 ` Namhyung Kim [this message]
2025-01-30 17:46 ` [PATCH v5 0/4] Prefer sysfs/JSON events also when no PMU is provided Namhyung Kim
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=Z5qmHaHRtWKnG4vT@google.com \
--to=namhyung@kernel.org \
--cc=Aditya.Bodkhe1@ibm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=asmadeus@codewreck.org \
--cc=bpf@vger.kernel.org \
--cc=hejunhao3@huawei.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jean-philippe.romain@foss.st.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=weilin.wang@intel.com \
--cc=zegao2021@gmail.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;
as well as URLs for NNTP newsgroup(s).