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

[James Clark]

On 20/12/2024 7:42 pm, Arnaldo Carvalho de Melo wrote:
> 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@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, applied to perf-tools-next,
>
> - Arnaldo

Just commenting to tie this into some related ideas that I put in the 
cover letter here: 
https://lore.kernel.org/linux-perf-users/20250304-james-perf-hybrid-list-v1-0-a363ffac283c@xxxxxxxxxx/T/#m44b5da77819baa249d34bc5b2c7f10b65d3d7360