mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jing Zhang <renyu.zj@linux.alibaba.com>
To: John Garry <john.g.garry@oracle.com>,
	Ian Rogers <irogers@google.com>, Will Deacon <will@kernel.org>,
	Shuai Xue <xueshuai@linux.alibaba.com>,
	Robin Murphy <robin.murphy@arm.com>
Cc: James Clark <james.clark@arm.com>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ilkka Koskinen <ilkka@os.amperecomputing.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	Zhuo Song <zhuo.song@linux.alibaba.com>
Subject: Re: [PATCH v3 2/7] perf metric: Event "Compat" value supports matching multiple identifiers
Date: Thu, 1 Jun 2023 16:58:41 +0800	[thread overview]
Message-ID: <452e724b-2a2c-52fd-274b-60db7a7f730e@linux.alibaba.com> (raw)
In-Reply-To: <c1d8ee9b-4839-1011-4dad-c4777d8f8224@oracle.com>



在 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@linux.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);

  reply	other threads:[~2023-06-01  8:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30  9:19 [PATCH v3 0/7] Add JSON metrics for arm CMN and Yitian710 DDR Jing Zhang
2023-05-30  9:19 ` [PATCH v3 1/7] driver/perf: Add identifier sysfs file for CMN Jing Zhang
2023-05-31  2:58   ` kernel test robot
2023-05-30  9:19 ` [PATCH v3 2/7] perf metric: Event "Compat" value supports matching multiple identifiers Jing Zhang
2023-05-31 13:18   ` John Garry
2023-06-01  8:58     ` Jing Zhang [this message]
2023-06-02 16:20       ` John Garry
2023-06-05  2:46         ` Jing Zhang
2023-06-05 19:39           ` Arnaldo Carvalho de Melo
2023-06-15  3:41             ` Jing Zhang
2023-06-23 23:52               ` Namhyung Kim
2023-06-25  8:55                 ` Jing Zhang
2023-06-06 14:11           ` John Garry
2023-06-08  9:44             ` Jing Zhang
2023-06-12 18:15               ` John Garry
2023-06-13 16:36                 ` John Garry
2023-06-15  2:18                   ` Jing Zhang
2023-06-16 11:41                     ` John Garry
2023-06-19  2:58                       ` Jing Zhang
2023-06-19  7:07                         ` John Garry
2023-06-19  8:59                           ` Jing Zhang
2023-06-19  9:31                             ` John Garry
2023-06-20  2:12                               ` Jing Zhang
2023-06-20  7:01                                 ` John Garry
2023-06-21  3:15                                   ` Jing Zhang
2023-06-06 16:27         ` Robin Murphy
2023-06-08 10:11           ` Jing Zhang
2023-05-30  9:19 ` [PATCH v3 3/7] perf vendor events: Add JSON metrics for CMN Jing Zhang
2023-05-31  1:18   ` Ian Rogers
2023-06-01  9:03     ` Jing Zhang
2023-05-31  2:43   ` Shuai Xue
2023-06-01  9:06     ` Jing Zhang
2023-05-30  9:19 ` [PATCH v3 4/7] driver/perf: Add identifier sysfs file for Yitian 710 DDR Jing Zhang
2023-05-30  9:19 ` [PATCH v3 5/7] perf jevents: Add support for Yitian 710 DDR PMU aliasing Jing Zhang
2023-05-30  9:19 ` [PATCH v3 6/7] perf vendor events: Add JSON metrics for Yitian 710 DDR Jing Zhang
2023-05-30  9:19 ` [PATCH v3 7/7] docs: perf: Update metric usage for Alibaba's T-Head PMU driver Jing Zhang
2023-05-31  1:19   ` Ian Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=452e724b-2a2c-52fd-274b-60db7a7f730e@linux.alibaba.com \
    --to=renyu.zj@linux.alibaba.com \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ilkka@os.amperecomputing.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=john.g.garry@oracle.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=namhyung@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=xueshuai@linux.alibaba.com \
    --cc=zhuo.song@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome