[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bk3hp3z7.wl-maz@kernel.org>
Date: Mon, 01 Jul 2024 15:43:40 +0100
From: Marc Zyngier <maz@...nel.org>
To: Yangyu Chen <cyy@...self.name>,
Will Deacon <will@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org,
Mark Rutland <mark.rutland@....com>,
Janne Grunau <j@...nau.net>,
Hector Martin <marcan@...can.st>,
Asahi Lina <lina@...hilina.net>,
asahi@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b
On Mon, 01 Jul 2024 15:19:59 +0100,
Marc Zyngier <maz@...nel.org> wrote:
>
> On Mon, 01 Jul 2024 15:01:48 +0100,
> Will Deacon <will@...nel.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@...self.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@...y-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@...y-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.
Powered by blists - more mailing lists