From: Mark Rutland <mark.rutland@arm.com>
To: James Clark <james.clark@arm.com>
Cc: Ian Rogers <irogers@google.com>, Marc Zyngier <maz@kernel.org>,
Hector Martin <marcan@marcan.st>,
Arnaldo Carvalho de Melo <acme@redhat.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: Thu, 23 Nov 2023 17:15:33 +0000 [thread overview]
Message-ID: <ZV-ItX1eMeIdo_00@FVFF77S0Q05N.cambridge.arm.com> (raw)
In-Reply-To: <96fa7b1a-9f64-315b-c767-e582db55c7a4@arm.com>
On Thu, Nov 23, 2023 at 05:08:43PM +0000, James Clark wrote:
> On 23/11/2023 16:48, Mark Rutland wrote:
> > Ah, so IIUC what's happening is:
> >
> > 1) Userspace tries to detect extended type support, with a cycles event
> > directed to one of the CPU PMUs. The attr for this does not have
> > exclude_guest set.
> >
> > 2) In the kernel, the core perf code sees the extended hw type id, and directs
> > this towards the correct PMU (apple_icestorm_pmu).
> >
> > 3) The PMU driver looks at the attr, sees exclude_guest is not set, and returns
> > -EOPNOTSUPP, exactly as it would regardless of whether the extended hw type
> > is used.
> >
> > Note: this happens to be a difference between x86 PMUs and the apple_* PMUs,
> > but this is a legitimate part of the perf ABI, not an arm-specific quirk or
> > bug.
> >
> > 4) Userspace receives -EOPNOTSUPP, and so decide the extended hw_type is not
> > supported (even though the kernel does support the extended hw type id, and
> > the event was rejected for orthogonal reasons).
> > It sounds like we need to make (4) more robust? I'm not immediately sure how,
> > given the rats nest of returns in perf_event_open(), but I'm happy to try to
> > help with that.
>
> It might be worth reporting extended HW ID support in the caps folder of
> the PMU so that Perf can look there instead of trying to open the event.
> It's something that we know will always be on or always be off so it
> doesn't make sense to try to discover it by opening an event.
Yep, I'm open to that idea. I'm more than happy to expose something that
indicates "this PMU supports the extended HW ID" and/or "this kernel supports
the extended HW ID".
Given that the actual PMU drivers don't see the extended cap, and that's
handled by the core, I'd like to make the core logic unconditional and remove
the kernel-internal PERF_PMU_CAP_EXTENDED_HW_TYPE cap. So I'd lean towards the
"this kernel supports the extended HW ID" option.
Thanks,
Mark.
next prev parent reply other threads:[~2023-11-23 17:15 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 12:08 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
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 [this message]
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=ZV-ItX1eMeIdo_00@FVFF77S0Q05N.cambridge.arm.com \
--to=mark.rutland@arm.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®