[PATCH v3 2/7] perf metric: Event "Compat" value supports matching multiple identifiers

[Jing Zhang]

在 2023/6/6 下午10:11, John Garry 写道:
> On 05/06/2023 03:46, Jing Zhang wrote:
>>> I assume that there is some ordering requirement for cmn_revision, considering that we have equality operations on the revision in the driver.
>>>
>> Actually revision is a register value rather than an enumeration value.
> 
> ok, got it.
> 
>> If I modify the revision to r0p0, etc., it is also possible, but I need
>> to convert the enumeration to a string.
> 
> understood
> 
>>
>>
>>>> The identifier consists of model_name and revision.
>>>> The compatible value "arm_cmn600;arm_cmn650" can match the identifier "arm_cmn600_0" or "arm_cmn650_0". Maybe the message log
>>>> is not clear enough.
>>>>
>>>> For example in patch #3 the metric "slc_miss_rate" is a generic metric for cmn-any. So we can define:
>>>>
>>>> +    {
>>>> +        "MetricName": "slc_miss_rate",
>>>> +        "BriefDescription": "The system level cache miss rate include.",
>>>> +        "MetricGroup": "arm_cmn",
>>>> +        "MetricExpr": "hnf_cache_miss / hnf_slc_sf_cache_access",
>>>> +        "ScaleUnit": "100%",
>>>> +        "Unit": "arm_cmn",
>>>> +        "Compat": "arm_cmn600;arm_cmn650;arm_cmn700;arm_ci700"
>>>> +    },
>>>>
>>>>
>>>> It can match identifiers "arm_cmn600_{0,1,2..X}" or "arm_cmn650_{0,1,2..X}" or "arm_cmn700_{0,1,2..X}" or "arm_ci700_{ 0,1,2..X}".
>>>> In other words, it can match all identifiers prefixed with “arm_cmn600” or “arm_cmn650” or “arm_cmn700” or “arm_ci700”.
>>>>
>>>> If a new model arm_cmn driver with identifier "arm_cmn750_0", it will not be matched, but if a new revision arm_cmn driver with identifier
>>>> "arm_cmn700_4", it can be matched.
>>> OK, I see what you mean. My confusion came about though your commit message on this same patch, which did not mention cmn650. I assumed that the example event which you were describing was supported for arm_cmn650 and you intentionally omitted it.
>>>
>> Yes, I didn't write cmn650 in the commit message, just because I omitted it. I will add it in a later version.
>>
>>>>
>>>>>> Tokens in Unit field are delimited by ';'.
>>>>> Thanks for taking a stab at solving this problem.
>>>>>
>>>>> I have to admit that I am not the biggest fan of having multiple values to match in the "Compat" value possibly for every event. It doesn't really scale.
>>>>>
>>>>> I would hope that there are at least some events which we are guaranteed to always be present. From what Robin said on the v2 series, for the implementations which we care about, events are generally added per subsequent version. So we should have some base set of fixed events.
>>>>>
>>>>> If we are confident that we have a fixed set of base set of events, can we ensure that those events would not require this compat string which needs each version explicitly stated?
>>>>>
>>>> If we are sure that some events will always exist in subsequent versions, we can set the Compat field to "arm_cmn;arm_ci". After that,
>>>> whether it is a different model or a different revision of the cmn PMU, it will be compatible. That is, it matches all whose identifier
>>>> is prefixed with “arm_cmn” or “arm_ci”.
>>> Sure, we could do something like that. Or if we are super-confident that every model and rev will support some event, then we can change perf tool to just not check Compat for that event.
>>>
>> Yes, I have also thought about this solution. If it is an event supported by all versions, as long as it meets the Unit match, it does not need
>> to check Compat.
> 
> 
>> However, the current perf tools tool seems to ignore the "Unit" inspection for the metric event.
> 
> Unit is the format of the event_source device name. We should match based on that as well as compat. I need to check the code again to understand how that is done... it has changed a good bit in 3 years.
> 

This situation only happens on uncore metric. I happened to write wrong Unit, but the metric still matches.

>>
>>>> Maybe it's not a perfect solution yet, looking forward to your suggestions.
>>> Well first we need to define kernel HW identifier format. I don't know why we don't encode model and revision name, like "cmn650_r1p1". Robin?
>>>
>> As mentioned earlier, revision is a register value rather than an enumeration value. If change revision to revision name, I need a more redundant
>> operation of converting enumeration value to string. If you think changing the naming method to "cmn650_r1p1" is clearer, of course
>> there is no problem.
> 
> It's just odd to mix a string and revision number in this way.
> 
> Robin knows more about this HW than me, so I'll let him decide on the the preferred format.
> 

Ok, thank you John.