lkml.org 
[lkml]   [2022]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs
From
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

\
 
 \ /
  Last update: 2022-05-18 15:51    [W:0.087 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site