[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zr4kZTxgvD6bmi37@x1>
Date: Thu, 15 Aug 2024 12:53:09 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: James Clark <james.clark@...aro.org>
Cc: Thorsten Leemhuis <regressions@...mhuis.info>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Ian Rogers <irogers@...gle.com>,
Mark Rutland <mark.rutland@....com>,
Linux perf Profiling <linux-perf-users@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
James Clark <james.clark@....com>,
"cc: Marc Zyngier" <maz@...nel.org>,
Hector Martin <marcan@...can.st>,
Asahi Linux <asahi@...ts.linux.dev>,
Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: [REGRESSION] Perf (userspace) broken on big.LITTLE systems since
v6.5
On Thu, Aug 15, 2024 at 12:27:21PM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, Aug 15, 2024 at 04:15:41PM +0100, James Clark wrote:
> > In one of your investigations here
> > https://lore.kernel.org/lkml/Zld3dlJHjFMFG02v@x1/ comparing "cycles",
> > "cpu-cycles" and "cpu_cycles" events on Arm you say only some of them open
> > events on both core types. I wasn't able to reproduce that on
> > perf-tools-next (27ac597c0e) or v6.9 (a38297e3fb) for perf record or stat. I
> > guessed the 6.9 tag because you only mentioned it was on tip and it was 29th
> > May. For me they all open exactly the same two legacy events with the
> > extended type ID set.
> >
> > It looks like the behavior you see would be caused by either missing this
> > kernel change:
> >
> > 5c81672865 ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability")
> > (v6.6 release)
What I have now is:
6.1.92-15907-gf36fd2695db3
It was a bit older, but 6.1 ish as well, I'll try to either get a new
kernel from Libre Computer or build one myself.
- Arnaldo
> > Or this userspace change, but unlikely as it was a fix for Apple M hardware:
> >
> > 25412c036 ("perf print-events: make is_event_supported() more robust")
> > (v6.9 release)
> >
> > Do you remember if you were using a new kernel or only testing a new Perf?
>
> I normally use the distro/SoC provided kernel, didn't I add the 'uname
> -a' output in those investigations (/me slaps himself in the face
> speculatively...)?
Powered by blists - more mailing lists