Re: [PATCH] perf top: Use evsel's cpus to replace user_requested_cpus

From: Ian Rogers
Date: Tue Dec 12 2023 - 13:00:35 EST


On Tue, Dec 12, 2023 at 9:23 AM Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
>
> On Tue, Dec 12, 2023 at 7:56 AM Liang, Kan <kan.liang@xxxxxxxxxxxxxxx> wrote:
> >
> >
> >
> > On 2023-12-11 4:13 p.m., Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Dec 08, 2023 at 01:08:55PM -0800, kan.liang@xxxxxxxxxxxxxxx escreveu:
> > >> From: Kan Liang <kan.liang@xxxxxxxxxxxxxxx>
> > >>
> > >> perf top errors out on a hybrid machine
> > >> $perf top
> > >>
> > >> Error:
> > >> The cycles:P event is not supported.
> > >>
> > >> The user_requested_cpus may contain CPUs that are invalid for a hybrid
> > >> PMU. It causes perf_event_open to fail.
> > >
> > > ?
> > >
> > > All perf top expects is that the "cycles", the most basic one, be
> > > collected, on all CPUs in the system.
> > >
> >
> > Yes, but for hybrid there is no single "cycles" event which can cover
> > all CPUs.
>
> Does that mean the kernel would reject the legacy "cycles" event
> on hybrid CPUs?

I believe not. When the extended type isn't set on legacy cycles we
often have the CPU and from that can determine the PMU. The issue is
with the -1 any CPU perf_event_open option. As I was told, the PMU the
event is opened on in this case is the first one registered in the
kernel, on Intel hybrid this could be cpu_core or cpu_atom.. but IIRC
it'll probably be cpu_core. On ARM ¯\_(ツ)_/¯. In any case you only
have an event that will be enabled on a fraction of the CPU cores the
thread you are monitoring could be scheduled on. This is why 2 or more
events are needed (depending on how many core types you have).

Thanks,
Ian

> Thanks,
> Namhyung