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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.