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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z5sLIiU7D6GwpWY1@google.com>
Date: Wed, 29 Jan 2025 21:16:18 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Kan Liang <kan.liang@...ux.intel.com>,
	James Clark <james.clark@...aro.org>, Ze Gao <zegao2021@...il.com>,
	Weilin Wang <weilin.wang@...el.com>,
	Dominique Martinet <asmadeus@...ewreck.org>,
	Jean-Philippe Romain <jean-philippe.romain@...s.st.com>,
	Junhao He <hejunhao3@...wei.com>, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
	Aditya Bodkhe <Aditya.Bodkhe1@....com>,
	Atish Patra <atishp@...osinc.com>, Leo Yan <leo.yan@....com>,
	Beeman Strong <beeman@...osinc.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH v5 4/4] perf parse-events: Reapply "Prefer sysfs/JSON
 hardware events over legacy"

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@...nel.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@...nel.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