Re: [PATCH v1] perf top: Merge hybrid common events

On Tue, Aug 18, 2026 at 10:29 AM Andi Kleen <[email protected]> wrote:
>
> > Thanks Andi, I agree with the frustration. For an event like
> > instructions I would like things merged. Does merging make sense for
> > cycles given the different clock frequencies of p-cores and e-cores?
>
> Frequencies are always per core anyways, even on non hybrid systems.
>
> > Should the e-core cycles be scaled for this reason as there are fewer
> > cycles within a second compared to a p-core?
>
> No.

Since we have frequency mode on events and the periods are aggregated,
I find it hard to fully think about the ramifications. Consider this
example: I have two identical loops, one loop runs on a p-core and the
other on an e-core, both accessing identical data that fits in the L1
cache. Since the IPC on the e-core is lower, the number of cycles it
spends in its loop should be higher. A user might mistakenly conclude
from the higher cycle count in one loop that cache/memory issues exist
in the e-core's loop, rather than realizing a scheduler issue caused
that loop to run on an e-core. If we detect a hybrid system we could
switch the default event to for all perf tools to instructions, as
instructions don't suffer from this problem.

> >
> > Perhaps we need a new json field to describe the hybrid merge-ability
> > of events, say enabled on events like instructions or cache misses.
> > Note the legacy events now have JSON descriptions:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/arch/common/common/legacy-hardware.json?h=perf-tools-next
>
> Makes sense. At least for architectural events it's easy.
> But I'll also defer it for now.

How can we merge non-legacy events? On ARM there is no PMU with a type
number file with TYPE_HARDWARE. It's not clear to me how legacy event
merging works outside of x86, although the issue is worse on Intel
given the lack of architectural event encodings that exist on
platforms like ARM - so the e-core and p-core perf_event_attr have
quite different config values.

> >
> > It would be nice if this were a generic feature and not just for perf top.
>
> Makes sense, but I would also defer that to a future version.
> The utility code is already partly factored out for reuse.

I think perf report should be easy given the overlap in code with perf
top. What about perf stat?

That reminds me: the enabled/running times are wrong with perf stat
and hybrid anyway. I posted this RFC that deserves more of my
attention:
https://lore.kernel.org/linux-perf-users/[email protected]/

Thanks,
Ian

> -Andi