Message ID | 1679885172-95021-1-git-send-email-renyu.zj@linux.alibaba.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1240004vqo; Sun, 26 Mar 2023 20:04:13 -0700 (PDT) X-Google-Smtp-Source: AKy350aZh4RPb1SXzQcyK1GGy6V3woSMmh4M9dTMvNPXZ2+HFSR6+jP08iHXYv8u/zMk7u6TGrmb X-Received: by 2002:a17:903:743:b0:1a1:cd69:d301 with SMTP id kl3-20020a170903074300b001a1cd69d301mr9544991plb.68.1679886252855; Sun, 26 Mar 2023 20:04:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679886252; cv=none; d=google.com; s=arc-20160816; b=GanSkTLo79vgXtibZ+iyS0pFNYQy3pe0ZY+JFsvSa+2essOJVIs96jZqH6W9Xs0HSn 1BTQeTJq1PmW4Ogg0NS1R6TkctVIs5t1qR0VASuOitR0UOPvdsFwsq3iSUvBSBVU7JWz TmykgtbTvtphVGx49FW7XE+ESOfFw1Bzm3wbghUsR04p+q9Ose+F3opzycFN2GXdwn1x EIrV0sbtDuNwBORTotzgnbFcZs7zcF35uZsOqSHTN2/mqeRk90yY8itNLWseCjn7es7O dIrxNZYN6uaVrPcargmsRSZ2THeaWOtMzkCVZXpQKxAPNd/2JsdVG6XYsU8gEn0zZsKK Qc3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=7fB1ZBy8YGUi0vuDb2hfZ4i3NS5GVaK7n1HlLJo1saI=; b=Gv1vNPEt51y8wQkExJeg6PtyxKK3qFeygKbALApVxZJPKd6OJjPxGV91eezsVEkWg3 OshYFviW8tqCgXaVlv07vyN74FGT2VGUi279aYWwAebyjSaEs7gHKpXfOYvhGbNPo4ea TnyNT+dtL3GOghH0sCVnkJy2LegXw+fokqMH7ZJzC1W0rVCVxS9a2dU8VYRtD/PmMe+r l8brVvbntrbFq+ci1kcI8AQV1Bg0FsL/dKs+345mxD0lCIpP+rM2nikXP3w/McLfP+QY nhBNIGvXctAAJqozhZlAl50n1uS3SdlvgjogsEBX/9EruQ6WmWoQcq1e0IAi6W0iqsct ZGfg== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 3-20020a631143000000b004fd72ef0180si26011677pgr.99.2023.03.26.20.04.00; Sun, 26 Mar 2023 20:04:12 -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 S231970AbjC0Cqc (ORCPT <rfc822;makky5685@gmail.com> + 99 others); Sun, 26 Mar 2023 22:46:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229677AbjC0Cq1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 26 Mar 2023 22:46:27 -0400 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3581144B1; Sun, 26 Mar 2023 19:46:26 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=renyu.zj@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0VeeqFMD_1679885175; Received: from srmbuffer011165236051.sqa.net(mailfrom:renyu.zj@linux.alibaba.com fp:SMTPD_---0VeeqFMD_1679885175) by smtp.aliyun-inc.com; Mon, 27 Mar 2023 10:46:23 +0800 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>, James Clark <james.clark@arm.com>, Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Adrian Hunter <adrian.hunter@intel.com> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, Shuai Xue <xueshuai@linux.alibaba.com>, Zhuo Song <zhuo.song@linux.alibaba.com>, Jing Zhang <renyu.zj@linux.alibaba.com> Subject: [PATCH RFC 0/4] Add JSON metrics for arm CMN and Yitian710 DDR Date: Mon, 27 Mar 2023 10:46:08 +0800 Message-Id: <1679885172-95021-1-git-send-email-renyu.zj@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 X-Spam-Status: No, score=-8.0 required=5.0 tests=ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=unavailable 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761488407156539503?= X-GMAIL-MSGID: =?utf-8?q?1761488407156539503?= |
Series |
Add JSON metrics for arm CMN and Yitian710 DDR
|
|
Message
Jing Zhang
March 27, 2023, 2:46 a.m. UTC
Hi all, I add an identifier sysfs file for the yitian710 SoC DDR and arm CMN to allow userspace to identify the specific implementation of the device, so that the perf tool can match the corresponding uncore events and metrics through the identifier. Then added several general CMN700 metrics and yitian710 soc DDR metrics. Since the eventid of cmn700 events is different from other events, it can't be specified by "EventCode" or "ConfigCode", so in the cmn.json file of cmn700, no "EventCode" and "ConfigCode" are added for these events. For example, the eventid of "arm_cmn_0/hnf_sf_hit is/": cat /sys/bus/event_source/devices/arm_cmn_0/events/hnf_sf_hit type=0x5,eventid=0x6 In addition, both cmn700 and ddr PMU can count the information in a die, but the same SoC can also be configured with different numbers of dies, so it is dificult to design a general expression to obtain metrics in different dies. The current yitian710 ddr bandwidth metric describes the sum of all dies bandwidth. I would like to ask you, is there any general expression can obtain metrics for die? Add an option to specify die? Thanks, Jing Jing Zhang (4): driver/perf: Add identifier sysfs file for CMN perf vendor events: Add JSON metrics for cmn700 driver/perf: Add identifier sysfs file for Yitian 710 DDR perf vendor events: Add JSON metrics for Yitian 710 DDR drivers/perf/alibaba_uncore_drw_pmu.c | 27 ++ drivers/perf/arm-cmn.c | 43 +++ .../pmu-events/arch/arm64/arm/cmn700/sys/cmn.json | 188 +++++++++++ .../arch/arm64/arm/cmn700/sys/metrics.json | 74 ++++ .../arm64/freescale/yitian710/sys/ali_drw.json | 373 +++++++++++++++++++++ .../arm64/freescale/yitian710/sys/metrics.json | 20 ++ tools/perf/pmu-events/jevents.py | 2 + 7 files changed, 727 insertions(+) create mode 100644 tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/cmn.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/metrics.json create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/ali_drw.json create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/metrics.json
Comments
On Sun, Mar 26, 2023 at 7:46 PM Jing Zhang <renyu.zj@linux.alibaba.com> wrote: > > Hi all, > > I add an identifier sysfs file for the yitian710 SoC DDR and arm CMN to > allow userspace to identify the specific implementation of the device, > so that the perf tool can match the corresponding uncore events and > metrics through the identifier. Then added several general CMN700 metrics > and yitian710 soc DDR metrics. Thanks! > Since the eventid of cmn700 events is different from other events, it > can't be specified by "EventCode" or "ConfigCode", so in the cmn.json > file of cmn700, no "EventCode" and "ConfigCode" are added for these > events. For example, the eventid of "arm_cmn_0/hnf_sf_hit is/": > cat /sys/bus/event_source/devices/arm_cmn_0/events/hnf_sf_hit > type=0x5,eventid=0x6 This is done to add descriptions to the events? We can add encodings to jevents.py and the event parsing to handle the names eventid and type. > In addition, both cmn700 and ddr PMU can count the information in a die, > but the same SoC can also be configured with different numbers of dies, > so it is dificult to design a general expression to obtain metrics in > different dies. The current yitian710 ddr bandwidth metric describes the > sum of all dies bandwidth. I would like to ask you, is there any general > expression can obtain metrics for die? Add an option to specify die? So hopefully the logic for this is getting clearer in the perf-tools-next branch. When perf stat runs it will aggregate in a number of different ways, if you pass -A it will remove the aggregation, but you can also use --per-socket, per-die, .. The metrics take the individual counter values, say instructions and cycles and produce a metric like IPC. By default all the instruction counts are aggregated together, the cycles are aggregated together and then the metric produced on the two aggregated values. When -A or --per-die are passed, the appropriate amount of aggregation should be done then the metric computed multiple times. Are you asking for a way in a metric to take counts from one die and use them in the other's metric? For example, reads on one die are writes on the other? This is possible as we have all the counts in the tool. I've thought about this in the context of some metrics we have for AMD, but there is no support for this in the tool currently. Thanks, Ian > Thanks, > Jing > > Jing Zhang (4): > driver/perf: Add identifier sysfs file for CMN > perf vendor events: Add JSON metrics for cmn700 > driver/perf: Add identifier sysfs file for Yitian 710 DDR > perf vendor events: Add JSON metrics for Yitian 710 DDR > > drivers/perf/alibaba_uncore_drw_pmu.c | 27 ++ > drivers/perf/arm-cmn.c | 43 +++ > .../pmu-events/arch/arm64/arm/cmn700/sys/cmn.json | 188 +++++++++++ > .../arch/arm64/arm/cmn700/sys/metrics.json | 74 ++++ > .../arm64/freescale/yitian710/sys/ali_drw.json | 373 +++++++++++++++++++++ > .../arm64/freescale/yitian710/sys/metrics.json | 20 ++ > tools/perf/pmu-events/jevents.py | 2 + > 7 files changed, 727 insertions(+) > create mode 100644 tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/cmn.json > create mode 100644 tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/metrics.json > create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/ali_drw.json > create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/metrics.json > > -- > 1.8.3.1 >
在 2023/3/28 上午12:51, Ian Rogers 写道: > On Sun, Mar 26, 2023 at 7:46 PM Jing Zhang <renyu.zj@linux.alibaba.com> wrote: >> >> Hi all, >> >> I add an identifier sysfs file for the yitian710 SoC DDR and arm CMN to >> allow userspace to identify the specific implementation of the device, >> so that the perf tool can match the corresponding uncore events and >> metrics through the identifier. Then added several general CMN700 metrics >> and yitian710 soc DDR metrics. > > Thanks! > >> Since the eventid of cmn700 events is different from other events, it >> can't be specified by "EventCode" or "ConfigCode", so in the cmn.json >> file of cmn700, no "EventCode" and "ConfigCode" are added for these >> events. For example, the eventid of "arm_cmn_0/hnf_sf_hit is/": >> cat /sys/bus/event_source/devices/arm_cmn_0/events/hnf_sf_hit >> type=0x5,eventid=0x6 > > This is done to add descriptions to the events? We can add encodings > to jevents.py and the event parsing to handle the names eventid and > type. > Ok, I will try it. >> In addition, both cmn700 and ddr PMU can count the information in a die, >> but the same SoC can also be configured with different numbers of dies, >> so it is dificult to design a general expression to obtain metrics in >> different dies. The current yitian710 ddr bandwidth metric describes the >> sum of all dies bandwidth. I would like to ask you, is there any general >> expression can obtain metrics for die? Add an option to specify die? > > So hopefully the logic for this is getting clearer in the > perf-tools-next branch. When perf stat runs it will aggregate in a > number of different ways, if you pass -A it will remove the > aggregation, but you can also use --per-socket, per-die, .. The > metrics take the individual counter values, say instructions and > cycles and produce a metric like IPC. By default all the instruction > counts are aggregated together, the cycles are aggregated together and > then the metric produced on the two aggregated values. When -A or > --per-die are passed, the appropriate amount of aggregation should be > done then the metric computed multiple times. > Thanks! It is helpful. It solved my problem. Thanks, Jing > Are you asking for a way in a metric to take counts from one die and > use them in the other's metric? For example, reads on one die are > writes on the other? This is possible as we have all the counts in the > tool. I've thought about this in the context of some metrics we have > for AMD, but there is no support for this in the tool currently. > > Thanks, > Ian > >> Thanks, >> Jing >> >> Jing Zhang (4): >> driver/perf: Add identifier sysfs file for CMN >> perf vendor events: Add JSON metrics for cmn700 >> driver/perf: Add identifier sysfs file for Yitian 710 DDR >> perf vendor events: Add JSON metrics for Yitian 710 DDR >> >> drivers/perf/alibaba_uncore_drw_pmu.c | 27 ++ >> drivers/perf/arm-cmn.c | 43 +++ >> .../pmu-events/arch/arm64/arm/cmn700/sys/cmn.json | 188 +++++++++++ >> .../arch/arm64/arm/cmn700/sys/metrics.json | 74 ++++ >> .../arm64/freescale/yitian710/sys/ali_drw.json | 373 +++++++++++++++++++++ >> .../arm64/freescale/yitian710/sys/metrics.json | 20 ++ >> tools/perf/pmu-events/jevents.py | 2 + >> 7 files changed, 727 insertions(+) >> create mode 100644 tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/cmn.json >> create mode 100644 tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/metrics.json >> create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/ali_drw.json >> create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/metrics.json >> >> -- >> 1.8.3.1 >>