Message-ID: <452e724b-2a2c-52fd-274b-60db7a7f730e@linux.alibaba.com>
Date:   Thu, 1 Jun 2023 16:58:41 +0800
From:   Jing Zhang <renyu.zj@...ux.alibaba.com>
To:     John Garry <john.g.garry@...cle.com>,
        Ian Rogers <irogers@...gle.com>, Will Deacon <will@...nel.org>,
        Shuai Xue <xueshuai@...ux.alibaba.com>,
        Robin Murphy <robin.murphy@....com>
Cc:     James Clark <james.clark@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Ilkka Koskinen <ilkka@...amperecomputing.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org,
        Zhuo Song <zhuo.song@...ux.alibaba.com>
Subject: Re: [PATCH v3 2/7] perf metric: Event "Compat" value supports
 matching multiple identifiers



在 2023/5/31 下午9:18, John Garry 写道:
> On 30/05/2023 10:19, Jing Zhang wrote:
>> The jevent "Compat" is used for uncore PMU alias or metric definitions.
>>
>> The same PMU driver has different PMU identifiers due to different hardware
>> versions and types, but they may have some common PMU event/metric. Since a
>> Compat value can only match one identifier, when adding the same event
>> alias and metric to PMUs with different identifiers, each identifier needs
>> to be defined once, which is not streamlined enough.
>>
>> So let "Compat" value supports matching multiple identifiers. For example,
>> the Compat value "arm_cmn600;arm_cmn700;arm_ci700" can match the PMU
>> identifier "arm_cmn600X" or "arm_cmn700X" or "arm_ci700X", where "X" is a
>> wildcard.
> 
> From checking the driver, it seems that we have model names "arm_cmn600" and "arm_cmn650". Are you saying that "arm_cmn600X" would match for those? I am most curious about how "arm_cmn600X" matches "arm_cmn650".
> 

Hi John,

>From patch #1 we have identifiers "arm_cmn600_0" and "arm_cmn650_0" etc. 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.


>> 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”.

Maybe it's not a perfect solution yet, looking forward to your suggestions.


Thanks,
Jing


> Robin, please let us know what you think of this.
> 
> Thanks,
> John
> 
>>
>> Signed-off-by: Jing Zhang <renyu.zj@...ux.alibaba.com>
>> ---
>>   tools/perf/util/metricgroup.c | 24 +++++++++++++++++++++++-
>>   1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>> index f3559be..c12ccd9 100644
>> --- a/tools/perf/util/metricgroup.c
>> +++ b/tools/perf/util/metricgroup.c
>> @@ -456,6 +456,28 @@ struct metricgroup_iter_data {
>>       void *data;
>>   };
>>   +static bool match_pmu_identifier(const char *id, const char *compat)
>> +{
>> +    char *tmp = NULL, *tok, *str;
>> +    bool res;
>> +
>> +    str = strdup(compat);
>> +    if (!str)
>> +        return false;
>> +
>> +    tok = strtok_r(str, ";", &tmp);
>> +    for (; tok; tok = strtok_r(NULL, ";", &tmp)) {
>> +        if (!strncmp(id, tok, strlen(tok))) {
>> +            res = true;
>> +            goto out;
>> +        }
>> +    }
>> +    res = false;
>> +out:
>> +    free(str);
>> +    return res;
>> +}
>> +
>>   static int metricgroup__sys_event_iter(const struct pmu_metric *pm,
>>                          const struct pmu_metrics_table *table,
>>                          void *data)
>> @@ -468,7 +490,7 @@ static int metricgroup__sys_event_iter(const struct pmu_metric *pm,
>>         while ((pmu = perf_pmu__scan(pmu))) {
>>   -        if (!pmu->id || strcmp(pmu->id, pm->compat))
>> +        if (!pmu->id || !match_pmu_identifier(pmu->id, pm->compat))
>>               continue;
>>             return d->fn(pm, table, d->data);

Powered by blists - more mailing lists