Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp708610rwo; Wed, 2 Aug 2023 02:59:05 -0700 (PDT) X-Google-Smtp-Source: APBJJlGyyV0/OLceByYHig9ZuyX2UC+LhkhI375+1e21Ava//Fvq962QtWFET2Uxelf7PYngRxf1 X-Received: by 2002:a05:6358:5905:b0:12b:da97:aba6 with SMTP id g5-20020a056358590500b0012bda97aba6mr4681029rwf.24.1690970344661; Wed, 02 Aug 2023 02:59:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690970344; cv=none; d=google.com; s=arc-20160816; b=BUOnn8eAVamtUlI96cmLhPX0YcfaXKJxfrSNR56Zp6PAjkxo8czkGqvBJo3OmB8V/Y W1MxFWUGNw2ihcs5IVPy+yPkt5RSyjVZuEZBb7vSJDpYfHr7y70WXYRSgKqjLiw4vtqa G1T9RxXA8eCIraEQg4K0rIJ1RXo04r17SHnsHJoTpwiFJlFtWtrWIwETvZ85hOG2syPb w9ivIZUyd9W5yeMUxmA3GPgNapMKFycR5SO7BI5xDLwww1JlE4tD2VZNLNUMoVKB50GP 3S+al6lfxFwH6cXfU3v14LCG/m746hpNIocVfnsNhYgKg2D5IgW+ghqDGXDAOiAG3VrS 97Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:subject:user-agent:mime-version:date:message-id; bh=euIT38vf6YB4Zl5Y1kMLuXOiZTIVPu/P2EJo2uVXfa0=; fh=yGvdyWabkLoh9b5WKENNRQOh79jMfphGJFNAfWMigIk=; b=dn4WtjV/uHu0dPEZCk9wjzED/atafR0z4nsGRzx2aDPkzxTv/FNh/Y0+zScKwbQPan Xfl62N3XyelXNFdxGtqH0/iviW+MdAV+FZHaU1dYWhgoS2FU6D2LO0yjXkpET6wHPEkD KhHnY+jE3HCYnH+CBzFhmhQITTMqB6CK1kLbQc5P55kG03Z20Td8hoz2kgaro2tHB+6A Dq838fH4LYmB+0AwyYbg6ohWcycRQ7YixbE2kruqdgxJk9UZpZTWbC9LGH+vxlOiYVva zteXzVAxK6i29Z3EdKB9hMmCrGqPpBq3Mdk2U5JaofVv9poZGIkvt4+54FY8W75Qqs9T 8IKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b26-20020a6567da000000b0056428dcea78si7400544pgs.17.2023.08.02.02.58.51; Wed, 02 Aug 2023 02:59:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232103AbjHBJim (ORCPT + 99 others); Wed, 2 Aug 2023 05:38:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbjHBJik (ORCPT ); Wed, 2 Aug 2023 05:38:40 -0400 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B6C0E48; Wed, 2 Aug 2023 02:38:37 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=renyu.zj@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0VoucCun_1690969112; Received: from 30.221.150.97(mailfrom:renyu.zj@linux.alibaba.com fp:SMTPD_---0VoucCun_1690969112) by smtp.aliyun-inc.com; Wed, 02 Aug 2023 17:38:33 +0800 Message-ID: <8e207c71-5400-5427-ae83-a1e0b8f95e31@linux.alibaba.com> Date: Wed, 2 Aug 2023 17:38:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH v5 1/5] perf metric: Event "Compat" value supports matching multiple identifiers From: Jing Zhang To: John Garry Cc: Ian Rogers , Will Deacon , Mark Rutland , Robin Murphy , Ilkka Koskinen , Namhyung Kim , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-doc@vger.kernel.org, Zhuo Song , Shuai Xue References: <1690525040-77423-1-git-send-email-renyu.zj@linux.alibaba.com> <1690525040-77423-2-git-send-email-renyu.zj@linux.alibaba.com> <268b3891-be4b-5f63-eff3-7b6d83e906e9@oracle.com> <0801b73c-6649-8c54-8dca-276efc2a4967@linux.alibaba.com> In-Reply-To: <0801b73c-6649-8c54-8dca-276efc2a4967@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2023/7/31 下午6:59, Jing Zhang 写道: > > 在 2023/7/28 下午4:11, John Garry 写道: >> On 28/07/2023 07:17, 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 {abcde;123*} >> why not use a comma-separated list? that is more common >> > > Hi John, > > I use a semicolon instead of a comma because I want to distinguish it from the function > of the comma in "Unit" and avoid confusion between the use of commas in "Unit" and "Compat". > Because in “Compat”, the semicolon means "or". So I think semicolons are more appropriate, > what do you think? > >>> can match the PMU identifier "abcde" and the >>> the PMU identifier with the prefix "123", >> >> I have to admit that this is not a great example as it does not match an expected real-life scenario. I mean, I would not expect a PMU identifier for the same PMU to be in either format "abcde" or "123*". I would expect to be in only ever one format. >> > > Get, I'll pick a more appropriate example {43401;436*}(CMN600 r0p0 and all CMN650). > >>> where "*" is a wildcard. >>> Tokens in Unit field are delimited by ';' with no spaces. >>> >>> Signed-off-by: Jing Zhang >>> --- >>>   tools/perf/util/metricgroup.c |  2 +- >>>   tools/perf/util/pmu.c         | 27 ++++++++++++++++++++++++++- >>>   tools/perf/util/pmu.h         |  1 + >>>   3 files changed, 28 insertions(+), 2 deletions(-) >>> >>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c >>> index 5e9c657..ff81bc5 100644 >>> --- a/tools/perf/util/metricgroup.c >>> +++ b/tools/perf/util/metricgroup.c >>> @@ -477,7 +477,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 || !pmu_uncore_identifier_match(pmu->id, pm->compat)) >>>               continue; >>>             return d->fn(pm, table, d->data); >>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c >>> index ad209c8..3ae249b 100644 >>> --- a/tools/perf/util/pmu.c >>> +++ b/tools/perf/util/pmu.c >>> @@ -776,6 +776,31 @@ static bool pmu_uncore_alias_match(const char *pmu_name, const char *name) >>>       return res; >>>   } >>>   +bool pmu_uncore_identifier_match(const char *id, const char *compat) >>> +{ >>> +    char *tmp = NULL, *tok, *str; >>> +    bool res; >>> +    int n; >>> + >>> +    str = strdup(compat); >> >> why duplicate this? are you modifying something? >> > > This is really a redundant step, I will remove it. > Hi John, I reviewed this code again and found that it still needs to duplicate "compat" because "compat" is a const str* type and cannot be used as a parameter for the strtok_r function. If it is cast to char*, using "compat" as a parameter for strtok_r is also unsafe and can cause a "Segmentation fault" error. Therefore, let's keep the step of duplicating "compat". Thanks, Jing >>> +    if (!str) >>> +        return false; >>> + >>> +    tok = strtok_r(str, ";", &tmp); >>> +    for (; tok; tok = strtok_r(NULL, ";", &tmp)) { >>> +        n = strlen(tok); >>> +        if ((tok[n - 1] == '*' && !strncmp(id, tok, n - 1)) || >>> +            !strcmp(id, tok)) { >>> +            res = true; >>> +            goto out; >>> +        } >>> +    } >>> +    res = false; >>> +out: >>> +    free(str); >>> +    return res; >>> +} >>> + >>>   struct pmu_add_cpu_aliases_map_data { >>>       struct list_head *head; >>>       const char *name; >>> @@ -847,7 +872,7 @@ static int pmu_add_sys_aliases_iter_fn(const struct pmu_event *pe, >> >> This is not for metrics specifically. You are really doing 2x things here. I suggest that you split the patch out into 1st pmu.c change and 2nd metricgroup.c change >> > > Ok, will do. > >>>       if (!pe->compat || !pe->pmu) >>>           return 0; >>>   -    if (!strcmp(pmu->id, pe->compat) && >>> +    if (pmu_uncore_identifier_match(pmu->id, pe->compat) && >>>           pmu_uncore_alias_match(pe->pmu, pmu->name)) { >> >> nit: let's change order to check alias and then identifier >> > > Will do. > > > Thanks, > Jing > >>>           __perf_pmu__new_alias(idata->head, -1, >>>                         (char *)pe->name, >>> diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h >>> index b9a02de..9d4385d 100644 >>> --- a/tools/perf/util/pmu.h >>> +++ b/tools/perf/util/pmu.h >>> @@ -241,6 +241,7 @@ void pmu_add_cpu_aliases_table(struct list_head *head, struct perf_pmu *pmu, >>>   char *perf_pmu__getcpuid(struct perf_pmu *pmu); >>>   const struct pmu_events_table *pmu_events_table__find(void); >>>   const struct pmu_metrics_table *pmu_metrics_table__find(void); >>> +bool pmu_uncore_identifier_match(const char *id, const char *compat); >>>   void perf_pmu_free_alias(struct perf_pmu_alias *alias); >>>     int perf_pmu__convert_scale(const char *scale, char **end, double *sval); >> >> Thanks, >> John