From: James Clark <james.clark@linaro.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>,
Namhyung Kim <namhyung@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>,
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 v3 0/4] Prefer sysfs/JSON events also when no PMU is provided
Date: Mon, 23 Dec 2024 15:09:31 +0000 [thread overview]
Message-ID: <823e66dc-9ff4-4168-be54-2e800aef0b28@linaro.org> (raw)
In-Reply-To: <20241221192654.94344-1-irogers@google.com>
On 21/12/2024 7:26 pm, 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.
>
> v3: Make no events opening for perf record a failure as suggested by
> James Clark and Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>. Also,
> rebase.
Looks like this could be interacting with the dummy event for itrace
events which I must have missed before. Now it "fails" but the exit code
is 0 which some of the tests rely on. I noticed "Miscellaneous Intel PT
testing" is failing because its skip mechanism is broken:
$ sudo perf record -e intel_pt/aux-action=start-paused/u
Error:
Failure to open event 'intel_pt/aux-action=start-paused/u' on PMU
'intel_pt' which will be removed.
$ echo $?
0
So the test thinks it has the aux-action feature but it doesn't.
> 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
> 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 | 34 ++++++++++++---
> 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, 156 insertions(+), 74 deletions(-)
>
next prev parent reply other threads:[~2024-12-23 15:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-21 19:26 [PATCH v3 0/4] Prefer sysfs/JSON events also when no PMU is provided Ian Rogers
2024-12-21 19:26 ` [PATCH v3 1/4] perf evsel: Add pmu_name helper Ian Rogers
2024-12-21 19:26 ` [PATCH v3 2/4] perf stat: Fix find_stat for mixed legacy/non-legacy events Ian Rogers
2024-12-21 19:26 ` [PATCH v3 3/4] perf record: Skip don't fail for events that don't open Ian Rogers
2024-12-21 19:26 ` [PATCH v3 4/4] perf parse-events: Reapply "Prefer sysfs/JSON hardware events over legacy" Ian Rogers
2024-12-23 15:09 ` James Clark [this message]
2024-12-23 20:11 ` [PATCH v3 0/4] Prefer sysfs/JSON events also when no PMU is provided Ian Rogers
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=823e66dc-9ff4-4168-be54-2e800aef0b28@linaro.org \
--to=james.clark@linaro.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=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=namhyung@kernel.org \
--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