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

[Ian Rogers]

On Wed, Oct 23, 2024 at 9:21 AM Ian Rogers <irogers@xxxxxxxxxx> wrote:
>
> On Wed, Oct 23, 2024 at 2:34 AM Robin Murphy <robin.murphy@xxxxxxx> wrote:
> >
> > On 2024-10-23 5:06 am, Ian Rogers wrote:
> > > On Thu, Jun 6, 2024 at 11:15 AM Liang, Kan <kan.liang@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
> > >>> Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> > >>> ---
> > >>>   .../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@xxxxxxxxxxxxxxx>
> > >
> > > 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