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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <060b220d-f7d6-4594-9b2b-e878a2ba98c6@arm.com>
Date: Wed, 23 Oct 2024 10:33:54 +0100
From: Robin Murphy <robin.murphy@....com>
To: Ian Rogers <irogers@...gle.com>, "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: 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>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 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 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 :(

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.

Thanks,
Robin.

> 
> Thanks,
> Ian
> 
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices b/Documentation/ABI/testing/sysfs-bus-event_source-devices
>>> new file mode 100644
>>> index 000000000000..79b268319df1
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices
>>> @@ -0,0 +1,24 @@
>>> +What: /sys/bus/event_source/devices/<pmu>
>>> +Date: 2014/02/24
>>> +Contact:     Linux kernel mailing list <linux-kernel@...r.kernel.org>
>>> +Description: Performance Monitoring Unit (<pmu>)
>>> +
>>> +             Each <pmu> directory, for a PMU device, is a name
>>> +             optionally followed by an underscore and then either a
>>> +             decimal or hexadecimal number. For example, cpu is a
>>> +             PMU name without a suffix as is intel_bts,
>>> +             uncore_imc_0 is a PMU name with a 0 numeric suffix,
>>> +             ddr_pmu_87e1b0000000 is a PMU name with a hex
>>> +             suffix. The hex suffix must be more than two
>>> +             characters long to avoid ambiguity with PMUs like the
>>> +             S390 cpum_cf.
>>> +
>>> +             Tools can treat PMUs with the same name that differ by
>>> +             suffix as instances of the same PMU for the sake of,
>>> +             for example, opening an event. For example, the PMUs
>>> +             uncore_imc_free_running_0 and
>>> +             uncore_imc_free_running_1 have an event data_read;
>>> +             opening the data_read event on a PMU specified as
>>> +             uncore_imc_free_running should be treated as opening
>>> +             the data_read event on PMU uncore_imc_free_running_0
>>> +             and PMU uncore_imc_free_running_1.