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] [day] [month] [year] [list]

Message-ID: <Z2XIitYfFaZJltul@x1>
Date: Fri, 20 Dec 2024 16:42:02 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Robin Murphy <robin.murphy@....com>,
	"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>, 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 Fri, Dec 20, 2024 at 11:16:46AM -0800, Ian Rogers wrote:
> 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, applied to perf-tools-next,

- Arnaldo