linux-kernel - Re: [RFC PATCH v2] perf Documentation: Describe the PMU naming convention

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: <CAP-5=fVBsCxHbqQkEbG2zzATDYfN8bP6mN9ixkae7o9eNB5w+Q@mail.gmail.com>
Date: Fri, 20 Dec 2024 11:16:46 -0800
From: Ian Rogers <irogers@...gle.com>
To: Robin Murphy <robin.murphy@....com>
Cc: "Liang, Kan" <kan.liang@...ux.intel.com>, Randy Dunlap <rdunlap@...radead.org>, 
	Tuan Phan <tuanphan@...amperecomputing.com>, Thomas Richter <tmricht@...ux.ibm.com>, 
	Bhaskara Budiredla <bbudiredla@...vell.com>, Bharat Bhushan <bbhushan2@...vell.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>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, James Clark <james.clark@....com>, 
	Ravi Bangoria <ravi.bangoria@....com>, linux-perf-users@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Will Deacon <will@...nel.org>, 
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [RFC PATCH v2] perf Documentation: Describe the PMU naming convention

On Wed, Oct 23, 2024 at 9:21 AM Ian Rogers <irogers@...gle.com> wrote:
>
> On Wed, Oct 23, 2024 at 2:34 AM Robin Murphy <robin.murphy@....com> wrote:
> >
> > On 2024-10-23 5:06 am, Ian Rogers wrote:
> > > On Thu, Jun 6, 2024 at 11:15 AM Liang, Kan <kan.liang@...ux.intel.com> wrote:
> > >>
> > >>
> > >>
> > >> On 2024-06-06 12:49 a.m., Ian Rogers wrote:
> > >>> It is an existing convention to use suffixes with PMU names. Try to
> > >>> capture that convention so that future PMU devices may adhere to it.
> > >>>
> > >>> The name of the file and date within the file try to follow existing
> > >>> conventions, particularly sysfs-bus-event_source-devices-events.
> > >>>
> > >>> Signed-off-by: Ian Rogers <irogers@...gle.com>
> > >>> Reviewed-by: Randy Dunlap <rdunlap@...radead.org>
> > >>> ---
> > >>>   .../testing/sysfs-bus-event_source-devices    | 24 +++++++++++++++++++
> > >>>   1 file changed, 24 insertions(+)
> > >>>   create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices
> > >>>
> > >>
> > >> Reviewed-by: Kan Liang <kan.liang@...ux.intel.com>
> > >
> > > Thanks for all the reviews. Could we land this?
> >
> > Hmm, it's not always going to be strictly true as written though - we
> > will also have cases where multiple PMU instances owned by the same
> > driver don't all support the same events/filters/etc., and/or are
> > entirely unrelated such that the same event encoding may mean completely
> > different things. I've just landed a driver where not only are the
> > instances going to be heterogeneous (since it's for arbitrary bits of
> > interconnect), but for hierarchy reasons the most logical place to put
> > the instance ID in the name wasn't even at the end :(
>
> Right, I was trying to capture what the tool is doing and trying to
> encompass the problems hex suffix create. Another example of that
> problem recently burning us is ARM's PMU naming of armv8_pmuv3_a53
> means the a53 looks like a hex suffix. When ARM release a model with a
> 3 digit number will the naming break? Wrt filters, I wonder if there
> should be testing, bugs, etc. The wildcard matching will likely do its
> thing and I think the failures should be predictable and descriptive,
> like an event used a format that a PMU doesn't support, but I'm not
> sure if we should do improvements in `perf list` where we try to
> deduplicate PMUs. Perhaps the deduplication should be smarter.
>
>
> > FWIW I think if we want to nail down a strict ABI, it would seem more
> > robust to have an explicit attribute to describe underlying PMU
> > properties like whether instances do represent identical "slices" or
> > not. The hex suffix thing is already proving how fragile names alone are
> > liable to be.
>
> Agreed. Does this mean we shouldn't land this? I worry that LKML is
> the home of bike shedding conversations and we're likely to bike shed
> trying to achieve 'perfect' while something 'good' would have value
> today.

Ping.

Thanks,
Ian