[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP-5=fXf9HtqKZyvfXNbKLTB-dL_Ax5Hd0_Gn1J-y0T1SE9wLQ@mail.gmail.com>
Date: Thu, 7 Nov 2024 10:51:58 -0800
From: Ian Rogers <irogers@...gle.com>
To: Atish Patra <atishp@...osinc.com>, James Clark <james.clark@...aro.org>,
linux-perf-users@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Ben Gainey <ben.gainey@....com>,
Junhao He <hejunhao3@...wei.com>, linux-riscv@...ts.infradead.org, beeman@...osinc.com,
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>, Jiri Olsa <jolsa@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Kan Liang <kan.liang@...ux.intel.com>,
Ze Gao <zegao2021@...il.com>, Weilin Wang <weilin.wang@...el.com>,
Dominique Martinet <asmadeus@...ewreck.org>
Subject: Re: [PATCH v1 0/4] Prefer sysfs/JSON events also when no PMU is provided
On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@...gle.com> 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.
Hi Atish and James,
Could I get your tags for this series?
The patches were originally motivated by wanting to make the behavior
of events parsed like "cycles" match that of "cpu/cycles/", the PMU is
wildcarded to "cpu" in the first case. This was divergent because of
ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE,
config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's
type>, config=<encoding from event>) when a PMU name was given. This
aligns with RISC-V wanting to use json encodings to avoid complexity
in the PMU driver.
James, could you show the neoverse with the cmn PMU behavior for perf
record of "cycles:pp" due to sensitivities there.
Thanks,
Ian
> 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 | 22 +++++++---
> 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, 145 insertions(+), 73 deletions(-)
>
> --
> 2.47.0.163.g1226f6d8fa-goog
>
Powered by blists - more mailing lists