Re: 'perf top' broken on intel hybrid systems

[Ian Rogers]

On Mon, Dec 11, 2023 at 1:11 PM Arnaldo Carvalho de Melo
<acme@xxxxxxxxxx> wrote:
>
> Em Fri, Dec 08, 2023 at 02:39:37PM -0500, Liang, Kan escreveu:
> > On 2023-12-08 1:57 p.m., Arnaldo Carvalho de Melo wrote:
> > >     So I finally got a recent Intel hybrid system:
> > > root@fedora:~# grep -m1 "model name" /proc/cpuinfo
> > > model name  : Intel(R) Core(TM) i7-14700K
> > > root@fedora:~#
> > >     Most things work, but:
>
> > > root@fedora:~# perf top
>
> > > Error:
> > > The cycles:P event is not supported.
> > > root@fedora:~#
> > >
> > > root@fedora:~# perf top -e cycles:p
> > > Error:
> > > The cycles:p event is not supported.
> > > root@fedora:~# perf top -e cycles:pp
> > > Error:
> > > The cycles:pp event is not supported.
> > > ^[[Aroot@fedora:~# perf top -e cycles:ppp
> > > Error:
> > > The cycles:ppp event is not supported.
> > > root@fedora:~#
> > > root@fedora:~# perf top -e cycles
> > > Error:
> > > The cycles event is not supported.
> > > root@fedora:~#
>
> > The error is because the perf top always tries to open an event on the
> > user_requested_cpus, which are all CPUs by default.
>
> But what is wrong with that for the default event, CPU cycles?
>
> It should work for all CPUs, its the most basic event, right?
>
> We should have a rough idea where CPU (no matter which CPUs) cycles are
> being used.

Generally we wouldn't want to aggregate cycles events on two differing
PMUs as the CPUs for them likely behave quite differently. Most of the
cycle event opening is now done by parsing "cycles:P" which will give
two evsels, one for each core PMU. You're right that the correct PMU
can be determined for the legacy events without an extended type if
the CPU isn't the -1 any CPU value. We'd need special parsing to make
this work in the context of perf top, which doesn't seem desirable. I
think we should support wild card PMUs and fix the CPU maps like we do
in perf stat and perf record.

Thanks,
Ian