Re: [PATCH v5 4/4] perf parse-events: Reapply "Prefer sysfs/JSON hardware events over legacy"

[Namhyung Kim <namhyung@kernel.org>]

On Wed, Jan 29, 2025 at 05:16:58PM -0800, Ian Rogers wrote:
> On Wed, Jan 29, 2025 at 1:55 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > On Wed, Jan 15, 2025 at 01:20:32PM -0800, Ian Rogers wrote:
> > > On Wed, Jan 15, 2025 at 9:59 AM Namhyung Kim <namhyung@kernel.org> wrote:
> > > > I think the behavior should be:
> > > >
> > > >   cycles -> PERF_COUNT_HW_CPU_CYCLES
> > > >   cpu-cycles -> PERF_COUNT_HW_CPU_CYCLES
> > > >   cpu_cycles -> no legacy -> sysfs or json
> > > >   cpu/cycles/ -> sysfs or json
> > > >   cpu/cpu-cycles/ -> sysfs or json
> > >
> > > So I disagree as if you add a PMU to an event name the encoding
> > > shouldn't change:
> > > 1) This historically was perf's behavior.
> >
> > Well.. I'm not sure about the history.  I believe the logic I said above
> > is the historic and (I think) right behavior.
> 
> You're wrong as you are describing the behavior post:
> https://lore.kernel.org/r/20231123042922.834425-1-irogers@google.com
> commit a24d9d9dc096fc0d0bd85302c9a4fe4fe3b1107b from Nov 2022, but
> somehow without legacy event fall backs which Intel added with a PMU
> for hybrid.
> 
> The behavior in this patch series is best for RISC-V, presumably ARM
> (particularly for Apple M? CPUs), carries ARM and Intel's tags,
> implements the behavior Arnaldo asked for, and solves the
> inconsistency that I think is fundamentally wrong in the tool that PMU
> names shouldn't matter on an event name (an inconsistency my past
> fixes introduced). It is also part of solving other problems:
> https://lore.kernel.org/linux-perf-users/20250127-counter_delegation-v3-0-64894d7e16d5@rivosinc.com/

So you think the below behavior is preferred, right?

  cycles -> cpu/cycles/ (or whatever PMU name) -> sysfs or json

And there's no way to use legacy event encodings anymore?

> 
> You've not pointed at anything wrong in the scheme that these patches
> introduce, and are supported by vendors, except that it is a behavior
> change. I can, and have, pointed at many issues with your proposal
> above and the current behavior. The behavior change came about to work
> around PMU bugs over 2 years ago but only partially did so. It makes
> sense to remedy this and for the clean, consistent behavior this
> series achieves. It is unfortunate that it is a behavior change, but
> the first step for that was made 2 years ago. I think it also makes
> sense that something self described as legacy is a lower priority and
> of the past (wrt event naming moving forward).

I want to clarify the event parsing behavior and to find the right way
to deal with various cases.  I haven't followed the activities in this
area closely so I missed some changes in the past.  Maybe the problem
is that the behavior is complex and not clarified.  Hopefully we can
write it down in a doc.

Thanks,
Namhyung