[PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b
Marc Zyngier
maz at kernel.org
Mon Jul 1 07:43:40 PDT 2024
On Mon, 01 Jul 2024 15:19:59 +0100,
Marc Zyngier <maz at kernel.org> wrote:
>
> On Mon, 01 Jul 2024 15:01:48 +0100,
> Will Deacon <will at kernel.org> wrote:
> >
> > On Thu, Jun 20, 2024 at 11:04:28AM +0800, Yangyu Chen wrote:
> > > Events 0x96 and 0x9b can be installed on counter 7 only. Fix this to avoid
> > > getting the wrong counter value.
> > >
> > > Signed-off-by: Yangyu Chen <cyy at cyyself.name>
> > > ---
> > > drivers/perf/apple_m1_cpu_pmu.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c
> > > index f322e5ca1114..b8127e5428e1 100644
> > > --- a/drivers/perf/apple_m1_cpu_pmu.c
> > > +++ b/drivers/perf/apple_m1_cpu_pmu.c
> > > @@ -107,12 +107,12 @@ static const u16 m1_pmu_event_affinity[M1_PMU_PERFCTR_LAST + 1] = {
> > > [M1_PMU_PERFCTR_UNKNOWN_93] = ONLY_5_6_7,
> > > [M1_PMU_PERFCTR_UNKNOWN_94] = ONLY_5_6_7,
> > > [M1_PMU_PERFCTR_UNKNOWN_95] = ONLY_5_6_7,
> > > - [M1_PMU_PERFCTR_UNKNOWN_96] = ONLY_5_6_7,
> > > + [M1_PMU_PERFCTR_UNKNOWN_96] = BIT(7),
> > > [M1_PMU_PERFCTR_UNKNOWN_97] = BIT(7),
> > > [M1_PMU_PERFCTR_UNKNOWN_98] = ONLY_5_6_7,
> > > [M1_PMU_PERFCTR_UNKNOWN_99] = ONLY_5_6_7,
> > > [M1_PMU_PERFCTR_UNKNOWN_9a] = BIT(7),
> > > - [M1_PMU_PERFCTR_UNKNOWN_9b] = ONLY_5_6_7,
> > > + [M1_PMU_PERFCTR_UNKNOWN_9b] = BIT(7),
> > > [M1_PMU_PERFCTR_UNKNOWN_9c] = ONLY_5_6_7,
> > > [M1_PMU_PERFCTR_UNKNOWN_9f] = BIT(7),
> > > [M1_PMU_PERFCTR_UNKNOWN_bf] = ONLY_5_6_7,
> >
> > It would be great if somebody with access to M1 hardware (and/or any
> > PMU insight) could Test or Ack this, please.
>
> I'm a bit concerned by this.
>
> I originally generated this table by hacking the counter setup so that
> it would try and count everywhere, and then feed the observations back
> into the driver.
>
> So either my methodology was flaky (not unlikely), but I'd then expect
> more of these mis-assignments, or this applies to an implementation
> that is different from the one I wrote this driver against (the
> original M1). Could it be that this for M2 only, and not M1? Or
> another flavour of M1?
>
> Either way, it would be good to understand how this has been
> established.
>
> In the meantime, I'll try and resurrect my original experiment and see
> if I spot the same issue.
A quick experiment shows that these events are counting on all 3
expected counters:
maz at mary-lou:~$ sudo taskset -c 8 perf stat -e r096:u -e r096:u -e r096:u sleep 5
Performance counter stats for 'sleep 5':
10,775 r096:u
10,775 r096:u
10,775 r096:u
5.000110823 seconds time elapsed
0.000340000 seconds user
0.000000000 seconds sys
maz at mary-lou:~$ sudo taskset -c 8 perf stat -e r09b:u -e r09b:u -e r09b:u sleep 5
Performance counter stats for 'sleep 5':
41,927 r09b:u
41,927 r09b:u
41,927 r09b:u
5.000109771 seconds time elapsed
0.000339000 seconds user
0.000000000 seconds sys
This is on M2 Pro, by the way, and I also checked that my M1 Ultra
counts the exact same way.
Yangyu, can you please clarify how you came to the conclusion that
these events didn't count anywhere other than counter 7?
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list