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

[James Clark <james.clark@linaro.org>]

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@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
> 

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@linaro.org/T/#m44b5da77819baa249d34bc5b2c7f10b65d3d7360