[PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b

Will Deacon will at kernel.org
Tue Jul 2 05:13:40 PDT 2024


On Tue, Jul 02, 2024 at 11:58:00AM +0100, Marc Zyngier wrote:
> On Tue, 02 Jul 2024 11:22:21 +0100,
> Yangyu Chen <cyy at 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.

I'd rather leave the code as-is than tweak specific counters based on
a combination of guesswork and partial information.

Of course, if somebody who knows better wants to fix up all of the
mappings (because this surely isn't the only corner-case), then we can
take that. But at least what we have today has _some_ sort of consistent
rationale behind it.

Will



More information about the linux-arm-kernel mailing list