[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-5=fX3U3JsRebOLWNQ-0n+W8aGWSLoDWYNZ9f4T7+sPa4H4g@mail.gmail.com>
Date: Thu, 6 Mar 2025 21:24:58 -0800
From: Ian Rogers <irogers@...gle.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Namhyung Kim <namhyung@...nel.org>, linux-perf-users@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>,
Thomas Falcon <thomas.falcon@...el.com>, Atish Patra <atishp@...osinc.com>,
James Clark <james.clark@...aro.org>, Leo Yan <leo.yan@...ux.dev>
Subject: Re: [RFC] perf tools: About encodings of legacy event names
On Mon, Feb 24, 2025 at 9:36 AM Ian Rogers <irogers@...gle.com> wrote:
>
> The series is trying to make "most people" happy with "no surprise"
So the patch [1] fixes a number of event grouping bugs present on all
Intel CPUs post Icelake (released April 2021). I think the code isn't
trivial, and I've tried to simplify everything as much as possible.
Again it shows the event parsing isn't a static problem and I am
trying to contribute fixes which this RFC on [2] is holding up.
On Alderlake I see problems:
```
$ perf stat -vv -e
'instructions,cpu_core/instructions/,cpu_atom/instructions/' perf test
-w noploop
Using CPUID GenuineIntel-6-B7-1
...
------------------------------------------------------------
perf_event_attr:
type 0 (PERF_TYPE_HARDWARE)
size 136
config 0xa00000001
(cpu_atom/PERF_COUNT_HW_INSTRUCTIONS/)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 1157109 cpu -1 group_fd -1 flags 0x8 = 5
------------------------------------------------------------
perf_event_attr:
type 0 (PERF_TYPE_HARDWARE)
size 136
config 0x400000001
(cpu_core/PERF_COUNT_HW_INSTRUCTIONS/)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 1157109 cpu -1 group_fd -1 flags 0x8 = 6
------------------------------------------------------------
perf_event_attr:
type 4 (cpu_core)
size 136
config 0xc0 (instructions)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 1157109 cpu -1 group_fd -1 flags 0x8 = 7
------------------------------------------------------------
perf_event_attr:
type 10 (cpu_atom)
size 136
config 0xc0 (instructions)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
------------------------------------------------------------
...
Performance counter stats for 'perf test -w noploop':
13,323,070,728 cpu_atom/instructions/
(1.87%)
26,695,170,453 cpu_core/instructions/
(98.13%)
26,695,170,453 cpu_core/instructions/
(98.13%)
13,323,070,728 cpu_atom/instructions/
(1.87%)
1.007358136 seconds time elapsed
1.003129000 seconds user
0.004012000 seconds sys
```
That is the instructions event, literally the 2nd legacy event after
cycles, getting 2 different encodings but the stat output showing the
events as if they are the same. The multiplexing numbers obviously
look off.
There is still work to do. Specifying a topdown event twice in an
event list currently breaks (e.g. `perf stat -e "slots,slots" ..`). I
see situations in perf-tools-next where a wildcard tries to open a
legacy event on even uncore PMUs.
Given [2] under pins so much I think merging it has to be a priority.
I suspect it needs rebasing and checking in the light of the changes
in [1]. Given it has extensive reviewing and testing by vendors, it
helps RISC-V and ARM Apple-M, I hope that after 2 weeks of this thread
that hasn't stimulated additional comment (beyond the original
comments on the series) things can move forward and fixing things can
continue.
Thanks,
Ian
[1] https://lore.kernel.org/lkml/20250307023906.1135613-3-irogers@google.com/
[2] https://lore.kernel.org/linux-perf-users/20250109222109.567031-5-irogers@google.com/#r
Powered by blists - more mailing lists