Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4141480rwb; Mon, 21 Nov 2022 04:21:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf4oBOt/8+maRBhCV17rjja1Is1Zw3zpRM7V6tcVNGdJ1SXmcHOYP9CCjOutSNAsbcArVKzU X-Received: by 2002:a63:747:0:b0:46f:2780:93b7 with SMTP id 68-20020a630747000000b0046f278093b7mr7791861pgh.166.1669033290346; Mon, 21 Nov 2022 04:21:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669033290; cv=none; d=google.com; s=arc-20160816; b=eeHO3kmkJBzrZxyPW0du0C/1FIuFob7PkxmQsHs3P4EmybzjBoYZHnEgnRHyLNtL1a bE7BuqC1z90xi8TIK+kbK/v1DPtCAHbZ3AaoD0y5tjq1G4oifA+QUHLEwlxolhGEDryU aTbaDtfIX93fUR/EPBC7Ly2RJjTHFliT/sYsFsfKu1FntRivTXRhfs+iiXmzWVs/5ec6 MtYOg64JP68h2boNTrCKHOaSj112CIxC/16gkVF6K/iAYip7v6hDYrg3ZvNMn01PgqsU EHCoOqvPPB/8wQxS1+75FVlcz61ThGmdJOJd1DX2apQh7eqkFHRupPPsaVoyUtba3t8p /87g== 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:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=08KMELtNEXUioxhGeD9j5/hZsojr+TZDPfkH+XYwB3s=; b=sDsQaBjY9aKPpleossJLVtXdOZqYNiOw973YfbpGP1wB7CqH6/Y7MjmEeiQNErnkGU qQ14yFDnQCq1xTW4KrYpECdX2Huvg4IySGBA9/zTU/LuUbz2LiqSrBFN66xNcz0Kjb86 O9WDU4HiK1/KrZyJZv7ClbXYxQPA1FX+61otw8w5aQHPrMeZYlOxIkAnwY1YoxmA+OtR EBiCXbQaXHN3LttAJwWrx6MdWZI9vYEiPlQWd7rS+tK+yPqj0lxUGxzI3UnutAiq9LWn NSlviF5+dbEj1o0TMd8Y7sD3y3aghHp8CEwvKwY8obtACjJV8Dfhyiww4024X5sJQCvo 9qyw== 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=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q19-20020a056a00089300b005631f695371si11718754pfj.127.2022.11.21.04.21.17; Mon, 21 Nov 2022 04:21:30 -0800 (PST) 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=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230320AbiKULzZ (ORCPT + 92 others); Mon, 21 Nov 2022 06:55:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbiKULzW (ORCPT ); Mon, 21 Nov 2022 06:55:22 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A71E41147F; Mon, 21 Nov 2022 03:55:21 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C67FB1FB; Mon, 21 Nov 2022 03:55:27 -0800 (PST) Received: from [10.57.6.6] (unknown [10.57.6.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 84E6A3F587; Mon, 21 Nov 2022 03:55:18 -0800 (PST) Message-ID: Date: Mon, 21 Nov 2022 11:55:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH RFC 0/6] Add metrics for neoverse-n2 Content-Language: en-US To: Ian Rogers , Jing Zhang Cc: nick Forrington , Jumana MP , John Garry , Will Deacon , Mike Leach , Leo Yan , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Andrew Kilroy , Shuai Xue , Zhuo Song , Linux ARM , linux-perf-users , LKML References: <1667214694-89839-1-git-send-email-renyu.zj@linux.alibaba.com> From: James Clark In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE 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 On 19/11/2022 21:46, Ian Rogers wrote: > On Fri, Nov 18, 2022 at 7:30 PM Jing Zhang > wrote: >> >> >> 在 2022/11/16 下午7:19, James Clark 写道: >>> >>> >>> On 31/10/2022 11:11, Jing Zhang wrote: >>>> This series add six metricgroups for neoverse-n2, among which, the >>>> formula of topdown L1 is from the document: >>>> > https://documentation-service.arm.com/static/60250c7395978b529036da86?token= >>>> >>>> Since neoverse-n2 does not yet support topdown L2, metricgroups such >>>> as Cache, TLB, Branch, InstructionsMix, and PEutilization are added to >>>> help further analysis of performance bottlenecks. >>>> >>> >>> Hi Jing, >>> >>> Thanks for working on this, these metrics look ok to me in general, >>> although we're currently working on publishing standardised metrics >>> across all new cores as part of a new project in Arm. This will include >>> N2, and our ones are very similar (or almost identical) to yours, >>> barring slightly different group names, metric names, and differences in >>> things like outputting topdown metrics as percentages. >>> >>> We plan to publish our standard metrics some time in the next 2 months. >>> Would you consider holding off on merging this change so that we have >>> consistant group names and units going forward? Otherwise N2 would be >>> the odd one out. I will send you the metrics when they are ready, and we >>> will have a script to generate perf jsons from them, so you can review. >>> >>> We also have a slightly different forumula for one of the top down >>> metrics which I think would be slightly more accurate. We don't have >>> anything for your "PE utilization" metrics, which I can raise >>> internally. It could always be added to perf on top of the standardised >>> ones if we don't add it to our standard ones. >>> >>> Thanks >>> James >>> >> >> Hi James, >> >> Regarding the arm n2 standard metrics last time, is my understanding > correct, >> and does it meet your meaning? If so, may I ask when you will send me the >> standards you formulate so that I can align with you in time over my > patchset. >> Please communicate this matter so that we can understand each other's > schedule. >> >> Thanks, >> Jing > > Hi, > > In past versions of the perf tool the metrics have been pretty broken. If > we have something that is good we shouldn't be holding it to a bar of being > perfect, we can merge what we have and improve over time. In this case what > Jing has prepared may arrive in time for Linux 6.2 whilst the standard > metrics may arrive in time for 6.3. I'd suggest merging Jing's work and > then improving on it with the standard metrics. > I'm not completely opposed to this, I was just worried about the churn because ours will be generated from a script, and that it would end up looking like a mass replacement of these that would have only recently been added. But maybe that's fine like you say. > In terms of the metrics themselves, could we add ScaleUnit? For example: > > + { > + "MetricExpr": "LD_SPEC / INST_SPEC", > + "PublicDescription": "The rate of load instructions speculatively > executed to overall instructions speclatively executed", > + "BriefDescription": "The rate of load instructions speculatively > executed to overall instructions speclatively executed", > + "MetricGroup": "InstructionMix", > + "MetricName": "load_spec_rate" > + }, > > A ScaleUnit of "100%" would likely make things more readable. > > Thanks, > Ian >