Messages in this thread | | | Date | Wed, 18 May 2022 14:48:17 +0100 | Subject | Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs | From | John Garry <> |
| |
On 18/05/2022 13:32, Robin Murphy wrote: >> If we were to add to arm32/arm then the common event numbers and maybe >> other JSONs in future would need to be duplicated. >> >> Would there be any reason to add to arm32/arm apart to from being >> strictly proper? Maybe if lots of other 32b support for other vendors >> came along then it could make sense (to separate them out). > > That's the heart of the question, really. At best it seems unnecessarily > confusing as-is.
I think it comes down to the first core supported was TX2 and the build system relies on the target arch to decide which arch from pmu-events/arch to compile.
> AFAICS either the naming isn't functional, wherein it > would potentially make the most sense to rename the whole thing > "pmu-events/arch/arm" if it's merely for categorising Arm architectures > in general, or it is actually tied to the host triplet, in which case > the above patches are most likely useless.
Today ARCH=arm has no pmu-events support. I think that it should be easy to add plumbing for that. It becomes more tricky with supporting a single "arm" folder.
But then do people really care enough about pmu-events for these 32b cores? Until now, it seems not.
> > I'd agree that there doesn't seem much point in trying to separate > things along relatively arbitrary lines if it *isn't* functionally > necessary - the PMUv2 common events look to be a straightforward subset > of the PMUv3 ones, but then there's Cortex-A32 anyway, plus most of the > already-supported CPUs could equally run an AArch32 perf tool as well.
Sure, we should have these 32b cores supported for ARCH=arm if they are supported for ARCH=arm64. But then does it even make sense to have A7 support in arch/arm64?
Thanks, John
| |