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: <65268cde-cefc-4c29-9ffc-7d85492ab125@linaro.org>
Date: Tue, 4 Mar 2025 13:54:05 +0000
From: James Clark <james.clark@...aro.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>,
 Ian Rogers <irogers@...gle.com>, Robin.Murphy@....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 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@...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
> 

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