Re: [PATCH v1] perf top: Merge hybrid common events
Andi Kleen <[email protected]>
| Newsgroups | org.kernel.vger.linux-perf-users |
|---|---|
| Message-ID | <aoXVrD-Qbhi5qd2D@tassilo> |
> 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? -Andi