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

[James Clark]

On 12/07/2023 10:22, John Garry wrote:
> On 11/07/2023 11:18, James Clark wrote:
>>>> 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).
> 
> If there are only very subtle differences, then could we solve with
> metric expression function? We already do something else like this for
> literal #slots for arm64

Possibly, but I'd have to add a new mechanism to expose the version
numbers to the metrics so it can be used in an expression. And I think
it could get very messy quite quickly and make the expression hard to
read. In fact in this specific case I'm not even sure how it would look.
Something like this (where #p is the p in r0p3)?

 {
 "ArchStdEvent": "bad_speculation",
 "MetricExpr": "(100 * (((1 - (OP_RETIRED / OP_SPEC)) * (1 -
((STALL_SLOT - (CPU_CYCLES if (#p >= 3) else 0) / (CPU_CYCLES *
#slots)))) + ((BR_MIS_PRED * 4) / CPU_CYCLES)))"
 },

In this case it's not so bad because we don't need to compare r as well,
but I think it could get worse if r was non 0 or there were more
significant differences to the metric.

It also doesn't scale in the same way when we're using auto generated
metrics with the data that Arm is publishing. We're going to treat CPU
versions as a completely new set of JSONs if there are any
differences/fixes in the PMU stuff and just publish a whole new set.
That way any tool that's consuming these can just check the MIDR and use
whichever JSONS are most appropriate. In theory this shouldn't require
any manual intervention or re-writing of expressions. And it saves every
tool having to solve the same problem.

It's possible in the future that there are also small changes to the
description text or availability of the events between versions. It
hasn't happened yet, but it gives us the flexibility to do that too.

> 
>> But it would also support the case where the event list was
>> slightly different between versions.
> 
> I am diff'ing folders ../arm64/arm/neoverse-n2r0p3-v2 and
> ../arm64/arm/neoverse-n2r0p0, and all the events are the same - am I
> correct? It only seems like metric json is different.
> 

Yes that's correct, just the topdown metrics where CPU_CYCLES was
subtracted as a workaround have been removed. N2 r0p3 no longer needs
that workaround. But everything else is the same.

I also used it as an opportunity to remove #slots from N2-r0p0. That set
of metrics will only be used in one place where slots is always 5. It's
better to hard code it so that it also has a chance to work on kernels
that don't have the change to expose slots yet.

>>
>>> 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,
> John
>