| 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
| ||
|
Message-ID: <CAP-5=fVd5OD2=hhfmGVLGXmnA6BbaSHkvOu5cAKOjV1UkUqxyw@mail.gmail.com>
Date: Mon, 3 Nov 2025 09:05:29 -0800
From: Ian Rogers <irogers@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
James Clark <james.clark@...aro.org>, Xu Yang <xu.yang_2@....com>,
Chun-Tse Shao <ctshao@...gle.com>, Thomas Richter <tmricht@...ux.ibm.com>,
Sumanth Korikkar <sumanthk@...ux.ibm.com>, Collin Funk <collin.funk1@...il.com>,
Thomas Falcon <thomas.falcon@...el.com>, Howard Chu <howardchu95@...il.com>,
Dapeng Mi <dapeng1.mi@...ux.intel.com>, Levi Yun <yeoreum.yun@....com>,
Yang Li <yang.lee@...ux.alibaba.com>, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
Weilin Wang <weilin.wang@...el.com>
Subject: Re: [PATCH v1 00/22] Switch the default perf stat metrics to json
On Thu, Oct 30, 2025 at 1:51 PM Ian Rogers <irogers@...gle.com> wrote:
>
> On Fri, Oct 24, 2025 at 10:59 AM Ian Rogers <irogers@...gle.com> wrote:
> >
> > Prior to this series stat-shadow would produce hard coded metrics if
> > certain events appeared in the evlist. This series produces equivalent
> > json metrics and cleans up the consequences in tests and display
> > output. A before and after of the default display output on a
> > tigerlake is:
> >
> > Before:
> > ```
> > $ perf stat -a sleep 1
> >
> > Performance counter stats for 'system wide':
> >
> > 16,041,816,418 cpu-clock # 15.995 CPUs utilized
> > 5,749 context-switches # 358.376 /sec
> > 121 cpu-migrations # 7.543 /sec
> > 1,806 page-faults # 112.581 /sec
> > 825,965,204 instructions # 0.70 insn per cycle
> > 1,180,799,101 cycles # 0.074 GHz
> > 168,945,109 branches # 10.532 M/sec
> > 4,629,567 branch-misses # 2.74% of all branches
> > # 30.2 % tma_backend_bound
> > # 7.8 % tma_bad_speculation
> > # 47.1 % tma_frontend_bound
> > # 14.9 % tma_retiring
> > ```
> >
> > After:
> > ```
> > $ perf stat -a sleep 1
> >
> > Performance counter stats for 'system wide':
> >
> > 2,890 context-switches # 179.9 cs/sec cs_per_second
> > 16,061,923,339 cpu-clock # 16.0 CPUs CPUs_utilized
> > 43 cpu-migrations # 2.7 migrations/sec migrations_per_second
> > 5,645 page-faults # 351.5 faults/sec page_faults_per_second
> > 5,708,413 branch-misses # 1.4 % branch_miss_rate (88.83%)
> > 429,978,120 branches # 26.8 K/sec branch_frequency (88.85%)
> > 1,626,915,897 cpu-cycles # 0.1 GHz cycles_frequency (88.84%)
> > 2,556,805,534 instructions # 1.5 instructions insn_per_cycle (88.86%)
> > TopdownL1 # 20.1 % tma_backend_bound
> > # 40.5 % tma_bad_speculation (88.90%)
> > # 17.2 % tma_frontend_bound (78.05%)
> > # 22.2 % tma_retiring (88.89%)
> >
> > 1.002994394 seconds time elapsed
> > ```
> >
> > Having the metrics in json brings greater uniformity, allows events to
> > be shared by metrics, and it also allows descriptions like:
> > ```
> > $ perf list cs_per_second
> > ...
> > cs_per_second
> > [Context switches per CPU second]
> > ```
> >
> > A thorn in the side of doing this work was that the hard coded metrics
> > were used by perf script with '-F metric'. This functionality didn't
> > work for me (I was testing `perf record -e instructions,cycles` and
> > then `perf script -F metric` but saw nothing but empty lines) but
> > anyway I decided to fix it to the best of my ability in this
> > series. So the script side counters were removed and the regular ones
> > associated with the evsel used. The json metrics were all searched
> > looking for ones that have a subset of events matching those in the
> > perf script session, and all metrics are printed. This is kind of
> > weird as the counters are being set by the period of samples, but I
> > carried the behavior forward. I suspect there needs to be follow up
> > work to make this better, but what is in the series is superior to
> > what is currently in the tree. Follow up work could include finding
> > metrics for the machine in the perf.data rather than using the host,
> > allowing multiple metrics even if the metric ids of the events differ,
> > fixing pre-existing `perf stat record/report` issues, etc.
> >
> > There is a lot of stat tests that, for example, assume '-e
> > instructions,cycles' will produce an IPC metric. These things needed
> > tidying as now the metric must be explicitly asked for and when doing
> > this ones using software events were preferred to increase
> > compatibility. As the test updates were numerous they are distinct to
> > the patches updating the functionality causing periods in the series
> > where not all tests are passing. If this is undesirable the test fixes
> > can be squashed into the functionality updates.
>
> Hi,
>
> no comments on this series yet, please help! I'd like to land this
> work and then rebase the python generating metric work [1] on it. The
> metric generation work is largely independent of everything else but
> there are collisions in the json Makefile/Build files.
Just to also add that the default perf stat output in perf-tools-next
looks like this on an Alderlake:
```
$ perf stat -a sleep 1
Performance counter stats for 'system wide':
0 cpu-clock # 0.000
CPUs utilized
19,362 context-switches
874 cpu-migrations
10,194 page-faults
633,489,938 cpu_atom/instructions/ # 0.69
insn per cycle (87.25%)
3,738,623,788 cpu_core/instructions/ # 2.05
insn per cycle
923,779,727 cpu_atom/cycles/
(87.28%)
1,821,165,755 cpu_core/cycles/
102,969,608 cpu_atom/branches/
(87.41%)
594,784,374 cpu_core/branches/
4,376,709 cpu_atom/branch-misses/ # 4.25% of
all branches (87.66%)
7,886,194 cpu_core/branch-misses/ # 1.33% of
all branches
# 10.4 % tma_bad_speculation
# 21.5 %
tma_frontend_bound
# 34.5 % tma_backend_bound
# 33.5 %
tma_retiring
# 17.7 % tma_bad_speculation
# 17.8 %
tma_retiring (87.64%)
# 33.4 % tma_backend_bound
# 31.1 %
tma_frontend_bound (87.67%)
1.004970242 seconds time elapsed
```
and this with the series:
```
$ perf stat -a sleep 1
Performance counter stats for 'system wide':
21,198 context-switches # nan
cs/sec cs_per_second
0 cpu-clock # 0.0
CPUs CPUs_utilized
989 cpu-migrations # nan
migrations/sec migrations_per_second
6,642 page-faults # nan
faults/sec page_faults_per_second
6,966,308 cpu_core/branch-misses/ # 1.3 %
branch_miss_rate
517,064,969 cpu_core/branches/ # nan
K/sec branch_frequency
1,602,405,292 cpu_core/cpu-cycles/ # nan
GHz cycles_frequency
3,012,408,051 cpu_core/instructions/ # 1.9
instructions insn_per_cycle
4,727,342 cpu_atom/branch-misses/ # 4.8 %
branch_miss_rate (49.79%)
94,075,578 cpu_atom/branches/ # nan
K/sec branch_frequency (50.14%)
922,932,356 cpu_atom/cpu-cycles/ # nan
GHz cycles_frequency (50.36%)
513,356,622 cpu_atom/instructions/ # 0.6
instructions insn_per_cycle (50.36%)
TopdownL1 (cpu_core) # 10.4 %
tma_bad_speculation
# 24.0 %
tma_frontend_bound
# 35.2 %
tma_backend_bound
# 30.4 %
tma_retiring
TopdownL1 (cpu_atom) # 36.1 %
tma_backend_bound (59.76%)
# 38.7 %
tma_frontend_bound (59.57%)
# 8.8 %
tma_bad_speculation
# 16.4 %
tma_retiring (59.57%)
1.006937573 seconds time elapsed
```
That is the TopdownL1 default group name is missing in the current
tree, etc. So just fixing the default perf stat output would be a good
reason to land this. The also broken output at the top is from a
tigerlake non-hybrid system.
Thanks,
Ian
> [1]
> * Foundations: https://lore.kernel.org/lkml/20240228175617.4049201-1-irogers@google.com/
> * AMD: https://lore.kernel.org/lkml/20240229001537.4158049-1-irogers@google.com/
> * Intel: https://lore.kernel.org/lkml/20240229001806.4158429-1-irogers@google.com/
> * ARM: https://lore.kernel.org/lkml/20240229001325.4157655-1-irogers@google.com/
Powered by blists - more mailing lists