[PATCH v2 2/5] perf jevents: Match on highest version of Arm json file available

[James Clark]

On 10/07/2023 17:56, John Garry wrote:
> On 10/07/2023 15:19, James Clark wrote:
> 
> +
> 
> 
> Hi James,
> 
> It would be good to cc some additional people and lists.

Hi John,

Resent a v3 with the normal get_maintainer list. I did this with the
first one but it bounced and for some reason with the v2 I reduced the
CC list. Not sure why really...

> 
>> Currently version and revision fields are masked out of the MIDR so
> 
> Do you mean variant and revision?
> 

Yes that should have been variant. Fixed in v3, thanks.

>> there can only be one set of jsons per CPU. In a later commit multiple
>> revisions of Neoverse N2 json files will be provided.
>>
> 
> 
>> The highest valid version of json files should be used,
> 
> What exactly does that mean?
> 
> So it seems that you have CPUs with matching MIDR except variant and
> revision, but have different events, right?

Yes. In this case we changed how a metric is calculated in N2-r0p3
because the workaround that was needed for r0p0 is no longer needed
(CPU_CYCLES should not subtracted from stalls for topdown metrics
anymore). But it would also support the case where the event list was
slightly different between versions.

> 
> Then to solve that are you saying that the highest version of the JSONs
> should used, upto and including the same CPU version (???) - correct?

Yeah pretty much. It's highest version of JSONs starting from
(including) the same CPU version, up to and not including the next
version of JSON files provided. If only r0p0 is provided then all CPU
versions match.

So if these JSONs were provided:

 r0p0  -  r0p4  -  r1p1

Would match these CPUs:

 CPU   |  JSON matched
 ------|---------------
 r0p0  |  r0p0
 r0p3  |  r0p0
 r0p4  |  r0p4
 r1p0  |  r0p4
 r1p1+ |  r1p1

> 
> The cover letter doesn't mention anything relevant :(
> 

Hopefully I expanded more in the v3 cover letter.

Thanks
James

>> but to make this
>> work the mapfile has to be reverse sorted on the CPUID field so that the
>> highest is found first.
>> It's possible, but error prone, to do this
>> manually so instead add an explicit sort into jevents.py. If the CPUID
>> is a string then the rows are string sorted rather than numerically.
>>
> 
> Thanks,
> John
>