From: Marc Zyngier <maz@kernel.org>
To: Yangyu Chen <cyy@cyyself.name>
Cc: Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>, Janne Grunau <j@jannau.net>,
Hector Martin <marcan@marcan.st>, Asahi Lina <lina@asahilina.net>,
asahi@lists.linux.dev,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b
Date: Tue, 02 Jul 2024 11:58:00 +0100 [thread overview]
Message-ID: <8634oshxhj.wl-maz@kernel.org> (raw)
In-Reply-To: <tencent_371517268623E4A61194EF4C70497BDC5105@qq.com>
On Tue, 02 Jul 2024 11:22:21 +0100,
Yangyu Chen <cyy@cyyself.name> wrote:
>
> > Yangyu, can you please clarify how you came to the conclusion that
> > these events didn't count anywhere other than counter 7?
> >
>
> IIRC, I came across some web page that says events 0x96 and 0x9b
> can only be installed on counter 7 to count Apple AMX, but I can't
> find the page now. Since AMX is not usable in Linux, I don't know
> if this will affect some other instructions that are usable in
> Linux.
As you said, AMX cannot be used with Linux, and that's unlikely to
ever change. But when it comes to the standard ARM ISA, we can only
witness counters 5,6 and 7 being incremented with at the exact same
rate.
So reading between the lines, what I understand is that AMX
instructions would only have their effects counted in counter 7 for
these events, while other instructions would be counted in all 3
counters.
By extension, such behaviour could be applied to SME on HW that
supports it (wild guess).
> There are some other reasons, but I can't say in public.
Fair enough, I'm not asking for the disclosure of anything that isn't
public (the least I know, the better).
> Even though I can't find the actual usage, I think using count 7
> only for these 2 events is safer. If this reason is insufficient,
> we can ignore this patch until we find other evidence that this
> affinity affects some instructions usable in Linux.
I honestly don't mind.
The whole thing is a black box, and is more useful as an interrupt
generator than an actual PMU, due to the lack of freely available
documentation. If the PMU maintainers want to merge this, I won't
oppose it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-07-02 10:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 3:04 [PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b Yangyu Chen
2024-07-01 14:01 ` Will Deacon
2024-07-01 14:19 ` Marc Zyngier
2024-07-01 14:43 ` Marc Zyngier
2024-07-02 10:22 ` Yangyu Chen
2024-07-02 10:58 ` Marc Zyngier [this message]
2024-07-02 12:13 ` Will Deacon
2024-07-02 12:43 ` Yangyu Chen
2024-07-08 12:00 ` Will Deacon
2024-07-23 16:24 ` Hector Martin
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=8634oshxhj.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=asahi@lists.linux.dev \
--cc=cyy@cyyself.name \
--cc=j@jannau.net \
--cc=lina@asahilina.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.rutland@arm.com \
--cc=will@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.