linux-kernel - Re: [RFC] perf tools: About encodings of legacy event names

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z8sMcta0zTWeOso4@x1>
Date: Fri, 7 Mar 2025 12:10:42 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: James Clark <james.clark@...aro.org>
Cc: Ian Rogers <irogers@...gle.com>, Namhyung Kim <namhyung@...nel.org>,
	linux-perf-users@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.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>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC] perf tools: About encodings of legacy event names

On Fri, Mar 07, 2025 at 02:17:22PM +0000, James Clark wrote:
> On 24/02/2025 3:01 pm, Arnaldo Carvalho de Melo wrote:
> > On Wed, Feb 19, 2025 at 10:37:33PM -0800, Ian Rogers wrote:
> > > I knew of this tech debt and separately RISC-V was also interested to
> > > have sysfs/json be the priority so that the legacy to config encoding
> > > could exist more in the perf tool than the PMU driver. I'm a SIG

> > I saw them saying that supporting PERF_TYPE_HARDWARE counters was ok as
> > they didn't want to break the perf tooling workflow, no?

> Doesn't most of the discussion stem from this particular point? I also
> understood it that way, that risc-v folks agreed it was better to support
> these to make all existing software work, not just Perf.

That is my understanding, and I agree with them and with you.

> Maybe one issue was calling them 'legacy' events in the first place, and I'm
> not sure if there is complete consensus that these are legacy.

I don't see them as "legacy".

> Can't they continue be the short easy list of events likely to be common across
> platforms?

That is my understanding of the original intent, yes.

A first approximation, those who want to dig deeper, well, learn more
about the architecture, learn about the extensive support for
vendor/JSON events, sysfs ones, how to properly configure them taking
advantage of the high level of flexibility both perf, the tool and perf
the kernel subsystem allows them to be used, in groups, leader sampling,
multiplexing or not, etc.

But lots of developers seem to be OK with just the default events or
using those aliases for expected events across architectures, sometimes
specifying :ppp as a hint that if there are more precise events in this
architecture, please use them, for instance.

> If there is an issue with some of them being wrong in some places
> we can move forward from that by making sure new platforms do it right,

And adding special case for broken things when we know that some event
named "cycles" shouldn't be used for sampling, for instance.

> rather than changing the logic for everyone to fix that bug.

Right. And again, if something doesn't work for a while in some
architecture, its just a matter of specifying the name of the event in
full form, with the PMU prefix, etc.

> For the argument that Google prefers to use the sysfs events because of
> these differences, I don't think there is anything preventing that kind of
> use today?

Indeed.

> Or at least not for the main priority flip proposed, but maybe
> there are some smaller adjacent bugs that can be fixed up separately.

Yes, and work in this area is greatly appreciated.

- Arnaldo