From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 00DCAC433EF for ; Fri, 8 Apr 2022 01:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KOUSIbXcH67H4svM29qGjzy8m4PkTXDlqEqGMV21CNM=; b=HE2fkwtyJyyCL4 /IYgi7kRGtoRj51VxZyrwDwjWWq/0fT4Qg80k+hq6w49nVlGiZ2kqkozoyiW/fECm+YaL3+qs/C5V WjBt3z3m71AiwJST4CV3vspyUE3z8r8x0/oef64rZ+fuF5Rydwv40v9xLwZ4sP/7asdawAbSmXf6H kQpgKJ+bGXObTwPI124CVXZ2UJO8hPJToZD962pvXvxp/MmcvOuuURfX2zWvNjR55o5ie4QgmMg1A rW2hwxyCFx9MZIXd6Wo08mGuapMyIyBWqTgn98i/LieDO95cMxmgdukTAj/7gQmsJr2Gmx3V+Cj7D Ad/3w7b2Yoli1wFShokw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncdHI-00EWFa-H8; Fri, 08 Apr 2022 01:19:08 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncdHF-00EWEU-69 for linux-arm-kernel@lists.infradead.org; Fri, 08 Apr 2022 01:19:06 +0000 Received: by mail-ej1-x62a.google.com with SMTP id dr20so14235445ejc.6 for ; Thu, 07 Apr 2022 18:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=ZBbnVt+YQv3guhlNFNXJxYGqdHwC1mgzxEzBpvoB+SY=; b=w0q8eVRm7h8rkmWA6aK++gCu1l3MsYOxmQ4NRzxqJmQPLXXIlRpBBIDfMzmDHECr7t TtW7WfmaPG3TgJXIbeOvoAEpjAFJfTf6e8jkEM8/qC4/WqEzi5oVjtegKjbhJjdwaqfv MQkSGt/u4A3k8V1cQDTccN7ypBxGvfg1BimSUF69kO0VkckMQJ2M37o6hp56SSyC8jmD ublaU+qy3+GSGXDg6f9rWwoI4T46vRUMl5F46DQYG8RajzVrYxiQJsnil81wzJXoRYJh K+w0IVmThRPv22Egt4dhG8A8BhD5shYjWWXo3tbE7zDIykX+0j47Ah+yAMNIerVOUfI/ 3l+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=ZBbnVt+YQv3guhlNFNXJxYGqdHwC1mgzxEzBpvoB+SY=; b=8Hg1QANNahTuPBpfAn62ShLAyZVb5HXJSQm3T5fGBboohKZ8WO/MTqfRCNlXQAvKda cr8nccQjVMMkXk2y2OX8O6Le3LCw98ZCHVKCbw9Jr2qydGT1DIpfYvozlUkOHbzPnjYq OBFVmMtqM+YximTx5adRC5Zc4fpXwXodfnxUIc7XOmzIPOTFgw9rxbj5aFB3U6vqwAbF wRm4e4thmH2xk+FeSm3Dr8/WZNbuVlFdMvFdh6ZviWbu++vFJU3poY5iknRlF2mqAEA2 UOWfpEb3hjIudv8daArfPpu/oRx6g3xCrAepHtKpPm6PQLdlARlY9RILgfD4WEv650Ha Decw== X-Gm-Message-State: AOAM532HW9irTRETnziWbcGNmR+9XubqH0x31J92HQymaaiWHvz7td+U 5TFX2c/WJ9INj67F+y2dRuivscIVPUyAQvnvXoGHaA== X-Google-Smtp-Source: ABdhPJwjkYqFIWmuU4xWDx/TspNGWQHzwEtaxjVLRLgAWrEaj1cS5hqzQdLBd4FyyYZWUiMFo0jjAA== X-Received: by 2002:a17:907:c21:b0:6e6:f1f3:ba77 with SMTP id ga33-20020a1709070c2100b006e6f1f3ba77mr16565078ejc.686.1649380740204; Thu, 07 Apr 2022 18:19:00 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([104.245.96.34]) by smtp.gmail.com with ESMTPSA id n6-20020aa7c786000000b00410d2403ccfsm9807040eds.21.2022.04.07.18.18.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 18:18:59 -0700 (PDT) Date: Fri, 8 Apr 2022 09:18:52 +0800 From: Leo Yan To: German Gomez Cc: Ali Saidi , Nick.Forrington@arm.com, acme@kernel.org, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, benh@kernel.crashing.org, james.clark@arm.com, john.garry@huawei.com, jolsa@kernel.org, kjain@linux.ibm.com, lihuafei1@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH v4 2/4] perf arm-spe: Use SPE data source for neoverse cores Message-ID: <20220408011852.GB973239@leoy-ThinkPad-X240s> References: <20220328130547.GA360814@leoy-ThinkPad-X240s> <20220329143214.12707-1-alisaidi@amazon.com> <4710b4b2-5dcd-00a4-3976-1bd5340f401d@arm.com> <20220331124425.GB1704284@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_181905_276113_9FB503C7 X-CRM114-Status: GOOD ( 27.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 07, 2022 at 04:24:35PM +0100, German Gomez wrote: > Hi, > = > On 31/03/2022 13:44, Leo Yan wrote: > > [...] > >>> I'd like to do this in a separate patch, but I have one other proposa= l. The > >>> Neoverse cores L2 is strictly inclusive of the L1, so even if it's in= the L1, > >>> it's also in the L2. Given that the Graviton systems and afaik the Am= pere > >>> systems don't have any cache between the L2 and the SLC, thus anythin= g from > >>> PEER_CORE, LCL_CLSTR, or PEER_CLSTR would hit in the L2, perhaps we > >>> should just set L2 for these cases? German, are you good with this fo= r now? = > >> Sorry for the delay. I'd like to also check this with someone. I'll try > >> to get back asap. In the meantime, if this approach is also OK with Le= o, > >> I think it would be fine by me. > = > Sorry for the delay. Yeah setting it to L2 indeed looks reasonable for > now. Somebody brought up the case of running SPE in a heterogeneous=A0 > system, but also we think might be beyond the scope of this change. > = > One very minor nit though. Would you be ok with renaming LCL to LOCAL=A0 > and CLSTR to CLUSTER? I sometimes mistead the former as "LLC". Ali's suggestion is to use the format: highest_cache_level | MEM_SNOOP_PEER. Simply to say, the highest cache level is where we snoop the cache data with the highest cache level. And we use an extra snoop op MEM_SNOOP_PEER as the flag to indicate a peer snooping from the local cluster or peer cluster. Please review the more detailed discussion in another email. > > Thanks for the checking internally. Let me just bring up my another > > thinking (sorry that my suggestion is float): another choice is we set > > ANY_CACHE as cache level if we are not certain the cache level, and > > extend snoop field to indicate the snooping logics, like: > > > > PERF_MEM_SNOOP_PEER_CORE > > PERF_MEM_SNOOP_LCL_CLSTR > > PERF_MEM_SNOOP_PEER_CLSTR > > > > Seems to me, we doing this is not only for cache level, it's more > > important for users to know the variant cost for involving different > > snooping logics. > > > I see there's been some more messages I need to catch up with. Is the=A0 > intention to extend the PERF_MEM_* flags for this cset, or will it be > left for a later change? The plan is to extend the PERF_MEM_* flags in this patch set. > In any case, I'd be keen to take another look at it and try to bring > some more eyes into this. Sure. Please check at your side and thanks for confirmation. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel