From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Hector Martin <marcan@marcan.st>, Ian Rogers <irogers@google.com>,
Marc Zyngier <maz@kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
James Clark <james.clark@arm.com>,
linux-perf-users@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Asahi Linux <asahi@lists.linux.dev>
Subject: Re: [REGRESSION] Perf (userspace) broken on big.LITTLE systems since v6.5
Date: Wed, 22 Nov 2023 13:19:34 -0300 [thread overview]
Message-ID: <ZV4qFtFctJ9emXvd@kernel.org> (raw)
In-Reply-To: <ZV4i_lrhbOVdEpwH@FVFF77S0Q05N>
Em Wed, Nov 22, 2023 at 03:49:18PM +0000, Mark Rutland escreveu:
> On Wed, Nov 22, 2023 at 10:06:23AM -0300, Arnaldo Carvalho de Melo wrote:
> > The point is that "cycles" when prefixed with "pmu/" shouldn't be
> > considered "cycles" as HW/0, in that setting it is "cycles" for that
> > PMU.
> Exactly.
> > (but we only have "cpu_cycles" for at least the a53 and a72 PMUs I
> > have access in a Libre Computer rockchip 3399-pc hybrid board, if we use
> > it, then we get what we want/had before, see below):
> Both Cortex-A53 and Cortex-A72 have the common PMUv3 events, so they have
> "cpu_cycles" and "bus_cycles".
root@roc-rk3399-pc:~# ls -la /sys/devices/*/events/*cycles
-r--r--r-- 1 root root 4096 Nov 22 12:35 /sys/devices/armv8_cortex_a53/events/bus_cycles
-r--r--r-- 1 root root 4096 Nov 22 12:35 /sys/devices/armv8_cortex_a53/events/cpu_cycles
-r--r--r-- 1 root root 4096 Nov 22 12:35 /sys/devices/armv8_cortex_a72/events/bus_cycles
-r--r--r-- 1 root root 4096 Nov 22 12:35 /sys/devices/armv8_cortex_a72/events/cpu_cycles
root@roc-rk3399-pc:~#
But on x86, on a AMD machine:
⬢[acme@toolbox ~]$ ls -la /sys/devices/*/events/*cycles
-r--r--r--. 1 nobody nobody 4096 Nov 22 12:48 /sys/devices/cpu/events/cpu-cycles
⬢[acme@toolbox ~]$
And an Intel:
[acme@quaco asahi]$ ls -la /sys/devices/*/events/*cycles
-r--r--r--. 1 root root 4096 Nov 22 13:11 /sys/devices/cpu/events/bus-cycles
-r--r--r--. 1 root root 4096 Nov 22 13:11 /sys/devices/cpu/events/cpu-cycles
-r--r--r--. 1 root root 4096 Nov 22 13:11 /sys/devices/cpu/events/ref-cycles
[acme@quaco asahi]$
Slight difference with those - and _.
> The Apple PMUs that Hector and Marc anre using don't follow the PMUv3
> architecture, and just have a "cycles" event.
I see, and even being prefixed with the PMU name, as
"apple_icestorm_pmu/cycles/" it ends up trumping that and moving that to
(PERF_TYPE_HARDWARE, PERF_HW_CPU_CYCLES) instead of
(/sys/devices/apple_icestorm_pmu/events/type,
/sys/devices/apple_icestorm_pmu/events/cycles) as I noticed with:
sys_perf_event_open: pid 0 cpu -1 group_fd -1 flags 0x8perf_event_open({type=PERF_TYPE_HARDWARE, size=0 /* PERF_ATTR_SIZE_??? */, config=0x7<<32|PERF_COUNT_HW_CPU_CYCLES, sample_period=0, sample_type=0, read_format=0, disabled=1, precise_ip=0 /* arbitrary skid */, ...}, 0, -1, -1, PERF_FLAG_FD_CLOEXEC) = -1 ENOENT (No such file or directory)
I.e.:
type=PERF_TYPE_HARDWARE, config=0x7<<32|PERF_COUNT_HW_CPU_CYCLES
It should be:
type=/sys/devices/apple_icestorm_pmu/events/type, config=/sys/devices/apple_icestorm_pmu/events/cycles
That is the minimal patch to address the regression reported, even if
using some kludge to buy time for a longer term more elegant solution,
Ian?
> [...]
> > So what we need here seems to be to translate the generic term "cycles"
> > to "cpu_cycles" when a PMU is explicitely passed in the event name and
> > it doesn't have "cycles" and then just retry.
>
> I'm not sure we need to map that.
>
> My thinking is:
>
> * If the user asks for "cycles" without a PMU name, that should use the
> PERF_TYPE_HARDWARE cycles event. The ARM PMUs handle that correctly when the
> event is directed to them.
>
> * If the user asks for "${pmu}/cycles/", that should only use the "cycles"
> event in that PMU's namespace, not PERF_TYPE_HARDWARE.
And thus, armv8_cortex_a53/cycles/ and armv8_cortex_a72/cycles/ should
just fail as there is no "cycles" for that PMU, no fallback.
> * If we need a way so say "use the PERF_TYPE_HARDWARE cycles event on ${pmu}",
> then we should have a new syntax for that (e.g. as we have for raw events),
> e.g. it would be possible to have "pmu/hw:cycles/" or something like that.
>
> That way there's no ambiguity.
- Arnaldo
next prev parent reply other threads:[~2023-11-22 16:19 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 12:08 [REGRESSION] Perf (userspace) broken on big.LITTLE systems since v6.5 Hector Martin
2023-11-21 13:40 ` Marc Zyngier
2023-11-21 15:24 ` Marc Zyngier
2023-11-21 15:40 ` Mark Rutland
2023-11-21 15:46 ` Ian Rogers
2023-11-21 16:02 ` Mark Rutland
2023-11-21 16:09 ` Ian Rogers
2023-11-21 16:15 ` Mark Rutland
2023-11-21 16:38 ` Ian Rogers
2023-11-22 3:23 ` Hector Martin
2023-11-22 13:06 ` Arnaldo Carvalho de Melo
2023-11-22 15:33 ` Ian Rogers
2023-11-22 15:49 ` Mark Rutland
2023-11-22 16:04 ` Ian Rogers
2023-11-22 16:26 ` Arnaldo Carvalho de Melo
2023-11-22 16:33 ` Ian Rogers
2023-11-22 16:19 ` Arnaldo Carvalho de Melo [this message]
2023-11-22 13:03 ` Mark Rutland
2023-11-22 15:29 ` Ian Rogers
2023-11-22 16:08 ` Mark Rutland
2023-11-22 16:29 ` Ian Rogers
2023-11-22 16:55 ` Arnaldo Carvalho de Melo
2023-11-22 16:59 ` Ian Rogers
2023-11-23 4:33 ` Ian Rogers
2023-11-21 15:41 ` Ian Rogers
2023-11-21 15:56 ` Mark Rutland
2023-11-21 16:03 ` Ian Rogers
2023-11-21 16:08 ` Mark Rutland
2023-11-23 14:23 ` Mark Rutland
2023-11-23 14:45 ` Marc Zyngier
2023-11-23 15:14 ` Ian Rogers
2023-11-23 16:48 ` Mark Rutland
2023-11-23 17:08 ` James Clark
2023-11-23 17:15 ` Mark Rutland
2023-11-21 23:43 ` Bagas Sanjaya
2023-12-06 12:09 ` Linux regression tracking #update (Thorsten Leemhuis)
2024-08-01 19:05 ` Ian Rogers
2024-08-07 8:54 ` Thorsten Leemhuis
2024-08-14 16:28 ` James Clark
2024-08-14 16:41 ` Arnaldo Carvalho de Melo
2024-08-15 15:15 ` James Clark
2024-08-15 15:20 ` James Clark
2024-08-15 15:27 ` Arnaldo Carvalho de Melo
2024-08-15 15:53 ` Arnaldo Carvalho de Melo
2024-08-16 8:57 ` James Clark
2024-08-15 17:29 ` Ian Rogers
2024-08-16 9:22 ` James Clark
2024-08-16 15:30 ` Ian Rogers
2024-08-17 1:38 ` Atish Kumar Patra
2024-08-20 8:58 ` James Clark
2024-08-19 14:56 ` James Clark
2024-08-19 15:44 ` Ian Rogers
2025-03-09 21:19 ` Ian Rogers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZV4qFtFctJ9emXvd@kernel.org \
--to=acme@kernel.org \
--cc=acme@redhat.com \
--cc=asahi@lists.linux.dev \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.