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

On Tue, Aug 18, 2026 at 8:34 PM Andi Kleen <[email protected]> wrote:
>
> On 2026-08-18 19:58, Ian Rogers wrote:
>
> > 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.
>
> You already have this problem in any other system from the last 20 years
> or
> so which has frequency scaling. There is nothing special here about
> hybrid.

With frequency scaling, doesn't IPC remain relatively constant with
frequency when ignoring external factors like memory? The IPC on an
e-core is expected to be lower than on a p-core.

> The scheduler has some internal magic to handle problems like this, but
> it's probably not directly applicable to user presented views.
>
> In perf there is also frequency mode (which is usually used with top)
> which
> kind of mitigates it anyways because it evens out the number of samples
> (at the cost of some terrible statistical properties, but that's a
> different chapter)
>
> Also in general people don't look at cycle counts, they look at
> percentages
> which scale per CPU.

So I was in a presentation today where someone claimed that larger
cycle counts translated to memory system overhead, but they could be
unique :-) In my two loop example the lower IPC core's loop would show
a greater number of cycles than the higher-IPC core's loop. This would
make it appear higher in `perf top`, leading the user to drill into it
assuming more time was spent there due to issues with the code. As I'm
hypothesizing the code is identical then the higher `perf top` is down
to being scheduled on the e-core and its lower IPC. Having identical
code where by default in perf one appears worse than the other doesn't
strike me as desirable as the same behavior wouldn't happen on a
non-hybrid system.

> > How can we merge non-legacy events? On ARM there is no PMU with a type
> > number file with TYPE_HARDWARE.
>
> Very few people use top with anything other than cycles, so it's
> probably
> not a very urgent problem.  I suppose you could push the problem to
> the user with some configuration file.

So I think users (and me) don't like the choose your event thing at
the beginning of `perf top`. I think the work in the histogram code to
combine hybrid events is valuable. I feel that cycle counts are open
to misinterpretation, so instructions should be used to avoid this.
Maybe we should just ask the user to select between merged, cpu_core
or cpu_atom at perf top startup, then misattributing cycles aggregated
on different cores was their selection. Maybe we should just warn
about cycle aggregation on hybrid in tips.txt:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Documentation/tips.txt

Thanks,
Ian

> -Andi