Re: [PATCH v1] perf top: Merge hybrid common events
Ian Rogers <[email protected]>
| Newsgroups | org.kernel.vger.linux-perf-users |
|---|---|
| Message-ID | <CAP-5=fW6a4MQurwVeL16WWFnO0VQPRm992M==DP9zVza3wgdfw@mail.gmail.com> |
On Wed, Aug 19, 2026 at 9:11 AM Andi Kleen <[email protected]> wrote: > > > 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. > > For most workloads you cannot ignore memory. > > Also the e-core IPC is often not lower than p-core, it's > actually quite competitive in many things. It just has > a much lower frequency ceiling. > > > 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. > > Yes performance analysis is hard and a lot of people get it wrong. > > > > > > > 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 > > I'm not sure what you're proposing here. You want to make > merging default to off? So I think we can add a json field to indicate mergeability and set it on legacy instructions, perhaps things like branches and branch-misses. We can also detect a hybrid system and switch from cycles to instructions as the default event when merging is desired (like in perf top). We can also give an extra prompt when selecting the event in perf top, perf report, .. where events can presumably be merged by name. For default perf stat I'm not sure what the behavior should be as we already expose different count values. Thanks, Ian > -Andi