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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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@google.com> wrote:
> >
> > On Wed, Oct 23, 2024 at 2:34 AM Robin Murphy <robin.murphy@arm.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@linux.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@google.com>
> > > >>> Reviewed-by: Randy Dunlap <rdunlap@infradead.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@linux.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