Re: [PATCH v2 00/16] Consistently prefer sysfs/json events

From: Ian Rogers <irogers@google.com>
To: Atish Kumar Patra <atishp@rivosinc.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>,
	 James Clark <james.clark@arm.com>,
	linux-perf-users@vger.kernel.org,  linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org,  linux-riscv@lists.infradead.org,
	Beeman Strong <beeman@rivosinc.com>
Subject: Re: [PATCH v2 00/16] Consistently prefer sysfs/json events
Date: Wed, 24 Apr 2024 08:14:02 -0700	[thread overview]
Message-ID: <CAP-5=fXqtvorr8JVwbEFubhAkcF2FTWNSzB+8G7En-9-rjfCdQ@mail.gmail.com> (raw)
In-Reply-To: <CAHBxVyF-u__MY9BNkqxUJg4ra76CzT0p_JBVaQqZm=u4V4u5AQ@mail.gmail.com>

On Tue, Apr 23, 2024 at 5:28 PM Atish Kumar Patra <atishp@rivosinc.com> wrote:
>
> On Mon, Apr 15, 2024 at 11:15 PM Ian Rogers <irogers@google.com> wrote:
> >
> > As discussed in:
> > https://lore.kernel.org/lkml/20240217005738.3744121-1-atishp@rivosinc.com/
> > preferring sysfs/json events consistently (with or without a given
> > PMU) will enable RISC-V's hope to customize legacy events in the perf
> > tool.
> >
>
> Thanks for remapping legacy events in a generic way. This looks great
> and got rid of my
> ugly arch specific way of remapping.  Is there a good way for the
> driver (e.g via sysfs) to tell the perf tool
> whether to remap the legacy event or not ?
>
> In RISC-V the legacy systems without the new ISA extension may not
> want to remap if running
> the latest kernel.
>
> I described the problem in detail in the original thread as well.
> https://lore.kernel.org/lkml/63d73f09-84e5-49e1-99f5-60f414b22d70@rivosinc.com/

So the sysfs/json events have priority over the legacy hardware events
with this patch series. I'm not clear on your question but here are
some scenarios:

1) for a vendor/model with a CPUID json files want to be used:
1.1) the driver shouldn't advertise the events /sys/devices/<pmu name>/events
1.2) the json in the perf tool needs to have a mapfile.csv entry for
the cpuid to a model directory containing the event json. In the
directory the legacy events should be defined.

2) for a vendor/model with a CPUID the driver files should be used:
2.1) the driver should advertise the events in /sys/devices/<pmu name>/events
2.2) in the json for the CPUID avoid redefining the events

3) for a vendor/model with a CPUID the legacy events should be used:
3.1) the driver shouldn't advertise the events in /sys/devices/<pmu name>/events
3.2) in the json for the CPUID avoid defining the events

Are you asking to have both sysfs and json events for a model? In this
case, which have priority over the other? It's possible in the pmu.c
code to have a prioritized lookup either from json then sysfs or
vice-versa, at the moment it is first come first served. To some
extent this can be seen on Intel uncore events where there are both
sysfs and json events with the same config, when we reverse map if the
sysfs name is loaded then it is reverse mapped in verbose log or by
perf trace, whilst typically I think the json name is reverse mapped.
Are you asking for the search order to be configurable by the driver?
In the past I've considered that the search order may be configured in
the tool and the user may want to provide their own directory
containing additional events and metrics.

> FWIW, for the entire series.
> Tested-by: Atish Patra <atishp@rivosinc.com>

Thanks, I think we can go ahead to land this. Kan's comment was to ask
for a follow up changing max_precise behavior and I'm hesitant to do
two behavior changes in 1 patch series.

Ian

> > Some minor clean-up is performed on the way.
> >
> > v2. Additional cleanup particularly adding better error messages. Fix
> >     some line length issues on the earlier patches.
> >
> > Ian Rogers (16):
> >   perf parse-events: Factor out '<event_or_pmu>/.../' parsing
> >   perf parse-events: Directly pass PMU to parse_events_add_pmu
> >   perf parse-events: Avoid copying an empty list
> >   perf pmu: Refactor perf_pmu__match
> >   perf tests parse-events: Use branches rather than cache-references
> >   perf parse-events: Legacy cache names on all PMUs and lower priority
> >   perf parse-events: Handle PE_TERM_HW in name_or_raw
> >   perf parse-events: Constify parse_events_add_numeric
> >   perf parse-events: Prefer sysfs/json hardware events over legacy
> >   perf parse-events: Inline parse_events_update_lists
> >   perf parse-events: Improve error message for bad numbers
> >   perf parse-events: Inline parse_events_evlist_error
> >   perf parse-events: Improvements to modifier parsing
> >   perf parse-event: Constify event_symbol arrays
> >   perf parse-events: Minor grouping tidy up
> >   perf parse-events: Tidy the setting of the default event name
> >
> >  tools/perf/tests/parse-events.c |   6 +-
> >  tools/perf/util/parse-events.c  | 482 ++++++++++++++++----------------
> >  tools/perf/util/parse-events.h  |  49 ++--
> >  tools/perf/util/parse-events.l  | 196 +++++++++----
> >  tools/perf/util/parse-events.y  | 261 +++++++----------
> >  tools/perf/util/pmu.c           |  27 +-
> >  tools/perf/util/pmu.h           |   2 +-
> >  7 files changed, 540 insertions(+), 483 deletions(-)
> >
> > --
> > 2.44.0.683.g7961c838ac-goog
> >