[PATCH] perf jevents: make events order more deterministic

[PATCH] perf jevents: make events order more deterministic

[Nazar Kazakov]

Some of the events have the same name, but differing descriptions. This
leads to a non-deterministic sorting order, so fix by adding the
description field to the order.

Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk>
---
 tools/perf/pmu-events/metric.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/pmu-events/metric.py b/tools/perf/pmu-events/metric.py
index a91ccb5977f0..b3ab78a0ecb2 100644
--- a/tools/perf/pmu-events/metric.py
+++ b/tools/perf/pmu-events/metric.py
@@ -623,7 +623,7 @@ class Metric:
 
   def __lt__(self, other):
     """Sort order."""
-    return self.name < other.name
+    return self.name < other.name or self.description < other.description
 
   def AddToMetricGroup(self, group):
     """Callback used when being added to a MetricGroup."""
-- 
2.54.0

Re: [PATCH] perf jevents: make events order more deterministic

[Ian Rogers]

On Mon, Jul 6, 2026 at 10:57 AM Nazar Kazakov
<nazar.kazakov@codethink.co.uk> wrote:
>
> Some of the events have the same name, but differing descriptions. This
> leads to a non-deterministic sorting order, so fix by adding the
> description field to the order.
>
> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk>

This shouldn't be an issue; can you give an example? I mean, with:
$ perf stat -e event1,event1 true
There's only one meaning for what event1 is. There is wildcard
support, but that's not the same as having the same event more than
once, differing only by description. Note, I deliberately use events
with perf stat in the example because the metrics build on the regular
event parsing code.

Thanks,
Ian

> ---
>  tools/perf/pmu-events/metric.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/pmu-events/metric.py b/tools/perf/pmu-events/metric.py
> index a91ccb5977f0..b3ab78a0ecb2 100644
> --- a/tools/perf/pmu-events/metric.py
> +++ b/tools/perf/pmu-events/metric.py
> @@ -623,7 +623,7 @@ class Metric:
>
>    def __lt__(self, other):
>      """Sort order."""
> -    return self.name < other.name
> +    return self.name < other.name or self.description < other.description
>
>    def AddToMetricGroup(self, group):
>      """Callback used when being added to a MetricGroup."""
> --
> 2.54.0
>

Re: [PATCH] perf jevents: make events order more deterministic

[Nazar Kazakov]

On 2026-07-06 19:04, Ian Rogers wrote:
> On Mon, Jul 6, 2026 at 10:57 AM Nazar Kazakov
> <nazar.kazakov@codethink.co.uk> wrote:
>> 
>> Some of the events have the same name, but differing descriptions. 
>> This
>> leads to a non-deterministic sorting order, so fix by adding the
>> description field to the order.
>> 
>> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk>
> 
> This shouldn't be an issue; can you give an example? I mean, with:
> $ perf stat -e event1,event1 true
> There's only one meaning for what event1 is. There is wildcard
> support, but that's not the same as having the same event more than
> once, differing only by description. Note, I deliberately use events
> with perf stat in the example because the metrics build on the regular
> event parsing code.

I meant sorting order during build time: 
tools/perf/pmu-events/pmu-events.c
changes between different builds, you can see an example of diffoscope
output here 
https://freedesktop-sdk.gitlab.io/-/freedesktop-sdk/-/jobs/15174060131/artifacts/result_folder/components/perf.bst/index.html

/* offset=5995059 */ 
"lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS, 
duration_time)\000\000L2 cache request for ownership (RFO) misses per 
second\000\0001misses/s\000\000\000\000000"
/* offset=5995210 */ 
"lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS, 
L2_RQSTS.RFO_HIT + L2_RQSTS.RFO_MISS)\000\000L2 cache request for 
ownership (RFO) misses\000\000100%\000\000\000\000000"

vs

/* offset=5995059 */ 
"lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS, 
L2_RQSTS.RFO_HIT + L2_RQSTS.RFO_MISS)\000\000L2 cache request for 
ownership (RFO) misses\000\000100%\000\000\000\000000"
/* offset=5995217 */ 
"lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS, 
duration_time)\000\000L2 cache request for ownership (RFO) misses per 
second\000\0001misses/s\000\000\000\000000"

That leads to non-reproducible binaries, even though the functionality
is probably the same.

Thanks,
Nazar Kazakov

Re: [PATCH] perf jevents: make events order more deterministic

[Ian Rogers]

On Mon, Jul 6, 2026 at 11:22 AM Nazar Kazakov
<nazar.kazakov@codethink.co.uk> wrote:
>
> On 2026-07-06 19:04, Ian Rogers wrote:
> > On Mon, Jul 6, 2026 at 10:57 AM Nazar Kazakov
> > <nazar.kazakov@codethink.co.uk> wrote:
> >>
> >> Some of the events have the same name, but differing descriptions.
> >> This
> >> leads to a non-deterministic sorting order, so fix by adding the
> >> description field to the order.
> >>
> >> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk>
> >
> > This shouldn't be an issue; can you give an example? I mean, with:
> > $ perf stat -e event1,event1 true
> > There's only one meaning for what event1 is. There is wildcard
> > support, but that's not the same as having the same event more than
> > once, differing only by description. Note, I deliberately use events
> > with perf stat in the example because the metrics build on the regular
> > event parsing code.
>
> I meant sorting order during build time:
> tools/perf/pmu-events/pmu-events.c
> changes between different builds, you can see an example of diffoscope
> output here
> https://freedesktop-sdk.gitlab.io/-/freedesktop-sdk/-/jobs/15174060131/artifacts/result_folder/components/perf.bst/index.html
>
> /* offset=5995059 */
> "lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS,
> duration_time)\000\000L2 cache request for ownership (RFO) misses per
> second\000\0001misses/s\000\000\000\000000"
> /* offset=5995210 */
> "lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS,
> L2_RQSTS.RFO_HIT + L2_RQSTS.RFO_MISS)\000\000L2 cache request for
> ownership (RFO) misses\000\000100%\000\000\000\000000"
>
> vs
>
> /* offset=5995059 */
> "lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS,
> L2_RQSTS.RFO_HIT + L2_RQSTS.RFO_MISS)\000\000L2 cache request for
> ownership (RFO) misses\000\000100%\000\000\000\000000"
> /* offset=5995217 */
> "lpm_l2_rfo_misses\000lpm_l2;lpm_l2_rfo\000d_ratio(L2_RQSTS.RFO_MISS,
> duration_time)\000\000L2 cache request for ownership (RFO) misses per
> second\000\0001misses/s\000\000\000\000000"
>
> That leads to non-reproducible binaries, even though the functionality
> is probably the same.

I agree non-reproducible builds are bad. The functionality should be
the same, the offsets exist only to avoid a gazillion C-string
constants that massively inflate the perf binary size which is about
75% string constants on x86. We don't want to relocate all those
strings when the perf binary loads.

I see the problem from your example. I wonder a more complete fix
would be something like:
```
   def __lt__(self, other):
     """Sort order."""
    if self.name != other.name:
        return self.name < other.name
    if not self.expr.Equals(other.expr):
        return self.expr.ToPerfJson() < other.expr.ToPerfJson()
    return self.description < other.description
```
wdyt?

Thanks,
Ian

> Thanks,
> Nazar Kazakov

Re: [PATCH] perf jevents: make events order more deterministic

[Nazar Kazakov]

On 2026-07-06 19:48, Ian Rogers wrote:

> I see the problem from your example. I wonder a more complete fix
> would be something like:
> ```
>    def __lt__(self, other):
>      """Sort order."""
>     if self.name != other.name:
>         return self.name < other.name
>     if not self.expr.Equals(other.expr):
>         return self.expr.ToPerfJson() < other.expr.ToPerfJson()
>     return self.description < other.description
> ```
> wdyt?

Yep, your code looks better. Also Sashiko AI tool found an embarrasing
bug in mine 
https://sashiko.dev/#/patchset/20260706175624.692736-1-nazar.kazakov@codethink.co.uk?part=1

So let's go with yours :)

Thanks,
Nazar Kazakov