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.
If I modify the revision to r0p0, etc., it is also possible, but I need
to convert the enumeration to a string.
Yes, I didn't write cmn650 in the commit message, just because I omitted it. I will add it in a later version.The identifier consists of model_name and revision.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.
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.
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 needSure, 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.
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,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?
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”.
to check Compat.
However, the current perf tools tool seems to ignore the "Unit" inspection for the metric event.
As mentioned earlier, revision is a register value rather than an enumeration value. If change revision to revision name, I need a more redundantMaybe 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?
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.