Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs

[John Garry <john.garry@huawei.com>]

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