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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32536C433FE for ; Mon, 14 Mar 2022 18:37:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239156AbiCNSin (ORCPT ); Mon, 14 Mar 2022 14:38:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234612AbiCNSik (ORCPT ); Mon, 14 Mar 2022 14:38:40 -0400 Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com [99.78.197.218]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC74E3EA9E; Mon, 14 Mar 2022 11:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1647283051; x=1678819051; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GNEfO5t/KNUf2cvjnQzdxGPpMnXGCdat3iHHsYtvCuM=; b=XQ/BYTJNS8Age5OM/27aEZrLC/auI4Pa0hF8ZMXhQaxgnZyq3A6Tw9A8 rM0ymeGXBPGSmq1GPEJsU0WmhmNtTC8JhHDcSvVwA7k1yBUSBFQnjc6bo PR+RJNxQJabRSkuYLVCqyU6GomLLKteQh4M7jzt3vWfZ+1mE4RLsT5Mad 8=; X-IronPort-AV: E=Sophos;i="5.90,181,1643673600"; d="scan'208";a="70825562" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-pdx-2b-0085f2c8.us-west-2.amazon.com) ([10.25.36.210]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP; 14 Mar 2022 18:37:30 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2b-0085f2c8.us-west-2.amazon.com (Postfix) with ESMTPS id 3289241EAE; Mon, 14 Mar 2022 18:37:23 +0000 (UTC) Received: from EX13D02UWC002.ant.amazon.com (10.43.162.6) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 14 Mar 2022 18:37:23 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D02UWC002.ant.amazon.com (10.43.162.6) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Mon, 14 Mar 2022 18:37:23 +0000 Received: from dev-dsk-alisaidi-1d-b9a0e636.us-east-1.amazon.com (172.19.181.128) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1497.28 via Frontend Transport; Mon, 14 Mar 2022 18:37:22 +0000 Received: by dev-dsk-alisaidi-1d-b9a0e636.us-east-1.amazon.com (Postfix, from userid 5131138) id BCEB7176D; Mon, 14 Mar 2022 18:37:22 +0000 (UTC) From: Ali Saidi To: CC: , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 2/2] perf mem: Support HITM for when mem_lvl_num is used Date: Mon, 14 Mar 2022 18:37:21 +0000 Message-ID: <20220314183721.3198-1-alisaidi@amazon.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi German and Leo, On Mon, 14 Mar 2022 18:00:13 +0000, German Gomez wrote: > Hi Leo, Ali > > On 14/03/2022 06:33, Leo Yan wrote: > > On Sun, Mar 13, 2022 at 07:19:33PM +0000, Ali Saidi wrote: > > > > [...] > > > >>>>> + if (lvl & P(LVL, L3) || lnum == P(LVLNUM, L4)) { > >>>> According to a comment in the previous patch, using L4 is specific to Neoverse, right? > >>>> > >>>> Maybe we need to distinguish the Neoverse case from the generic one here as well > >>>> > >>>> if (is_neoverse) > >>>> // treat L4 as llc > >>>> else > >>>> // treat L3 as llc > >>> I personally think it's not good idea to distinguish platforms in the decoding code. > >> I agree here. The more we talk about this, the more I'm wondering if we're > >> spending too much code solving a problem that doesn't exist. I know of no > >> Neoverse systems that actually have 4 cache levels, they all actually have three > >> even though it's technically possible to have four. I have some doubts anyone > >> will actually build four levels of cache and perhaps the most prudent path here > >> is to assume only three levels (and adjust the previous patch) until someone > >> actually produces a system with four levels instead of a lot of code that is > >> never actually exercised? > > I am not right person to say L4 cache is not implemented in Neoverse > > platforms; my guess for a "System cache" data source might be L3 or > > L4 and it is a implementation dependent. Maybe German or Arm mates > > could confirm for this. > > I had a look at the TRMs for the N1[1], V1[2] and N2[3] Neoverse cores > (specifically the LL_CACHE_RD pmu events). If we were to assign a number > to the system cache (assuming all caches are implemented): > > *For N1*, if L2 and L3 are implemented, system cache would follow at *L4* To date no one has built 4 level though. Everyone has only built three. > *For V1 and N2*, if L2 is implemented, system cache would follow at *L3* > (these don't seem to have the same/similar per-cluster L3 cache from the N1) And in the future they're not able to build >3. German and Leo if there aren't strong objections I think the best path forward is for me to respin these assuming only 3 levels and if someone builds 4 in a far-off-future we can always change the implementation then. Agreed? Thanks, Ali 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 AD407C433EF for ; Mon, 14 Mar 2022 18:38: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:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LOJ0jndCxn46t6uGYRhr5iOpVNOxWoUs5qOxL8au1ag=; b=QcccCa98lAflyA CBQMm47NCrAKzvWeHGbyswXmM9KSZPVd1h37SalWDCHe3eoDccX0h/sjmFgzkO/gT5+uKVNR38U7n lqvxeHEkbYNr/+3cVQjfVEaoYYrsxARZunowwCIjxQZOi1vB+DzmhHkyimsMKL088r8vtaMbSOTIO 25/FDFzzasxSMCigej9kBFmyPvbaxhWNdwB6MaOW/aoyDSOmBcwxMthBgQxJ5sItdH7bVQpGGRwPb W6Lh5ZghLCXG/ZAi552FNEXWjmpUW87YT/mHo4xXM96Lygyl4xtpbXeR9KYiouZXNc1uMixGLl42c 13Mhosm+XKpy/+dV1WQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTpZd-006XQ3-0J; Mon, 14 Mar 2022 18:37:41 +0000 Received: from smtp-fw-80007.amazon.com ([99.78.197.218]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTpZX-006XOW-TO for linux-arm-kernel@lists.infradead.org; Mon, 14 Mar 2022 18:37:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1647283057; x=1678819057; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GNEfO5t/KNUf2cvjnQzdxGPpMnXGCdat3iHHsYtvCuM=; b=IB7Au0KD+Uo/gt2f/reNpFHB6rG59dPQ2cUdr5n6TFGycT7+7Fpfy+bA mHhere7XLtqVZzudBA3k+JVJF1+vBq+s9KBJNUA3CMmVF9C8A4vsLPwNv +ETY+8C/aIRJhHpSaryNENscWMum6P9G2E1RQnnKe4lQfCuXDE3K/KQNw Y=; X-IronPort-AV: E=Sophos;i="5.90,181,1643673600"; d="scan'208";a="70825562" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-pdx-2b-0085f2c8.us-west-2.amazon.com) ([10.25.36.210]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP; 14 Mar 2022 18:37:30 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2b-0085f2c8.us-west-2.amazon.com (Postfix) with ESMTPS id 3289241EAE; Mon, 14 Mar 2022 18:37:23 +0000 (UTC) Received: from EX13D02UWC002.ant.amazon.com (10.43.162.6) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 14 Mar 2022 18:37:23 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D02UWC002.ant.amazon.com (10.43.162.6) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Mon, 14 Mar 2022 18:37:23 +0000 Received: from dev-dsk-alisaidi-1d-b9a0e636.us-east-1.amazon.com (172.19.181.128) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1497.28 via Frontend Transport; Mon, 14 Mar 2022 18:37:22 +0000 Received: by dev-dsk-alisaidi-1d-b9a0e636.us-east-1.amazon.com (Postfix, from userid 5131138) id BCEB7176D; Mon, 14 Mar 2022 18:37:22 +0000 (UTC) From: Ali Saidi To: CC: , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 2/2] perf mem: Support HITM for when mem_lvl_num is used Date: Mon, 14 Mar 2022 18:37:21 +0000 Message-ID: <20220314183721.3198-1-alisaidi@amazon.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: Bulk X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220314_113736_379909_0F888D79 X-CRM114-Status: GOOD ( 26.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi German and Leo, On Mon, 14 Mar 2022 18:00:13 +0000, German Gomez wrote: > Hi Leo, Ali > > On 14/03/2022 06:33, Leo Yan wrote: > > On Sun, Mar 13, 2022 at 07:19:33PM +0000, Ali Saidi wrote: > > > > [...] > > > >>>>> + if (lvl & P(LVL, L3) || lnum == P(LVLNUM, L4)) { > >>>> According to a comment in the previous patch, using L4 is specific to Neoverse, right? > >>>> > >>>> Maybe we need to distinguish the Neoverse case from the generic one here as well > >>>> > >>>> if (is_neoverse) > >>>> // treat L4 as llc > >>>> else > >>>> // treat L3 as llc > >>> I personally think it's not good idea to distinguish platforms in the decoding code. > >> I agree here. The more we talk about this, the more I'm wondering if we're > >> spending too much code solving a problem that doesn't exist. I know of no > >> Neoverse systems that actually have 4 cache levels, they all actually have three > >> even though it's technically possible to have four. I have some doubts anyone > >> will actually build four levels of cache and perhaps the most prudent path here > >> is to assume only three levels (and adjust the previous patch) until someone > >> actually produces a system with four levels instead of a lot of code that is > >> never actually exercised? > > I am not right person to say L4 cache is not implemented in Neoverse > > platforms; my guess for a "System cache" data source might be L3 or > > L4 and it is a implementation dependent. Maybe German or Arm mates > > could confirm for this. > > I had a look at the TRMs for the N1[1], V1[2] and N2[3] Neoverse cores > (specifically the LL_CACHE_RD pmu events). If we were to assign a number > to the system cache (assuming all caches are implemented): > > *For N1*, if L2 and L3 are implemented, system cache would follow at *L4* To date no one has built 4 level though. Everyone has only built three. > *For V1 and N2*, if L2 is implemented, system cache would follow at *L3* > (these don't seem to have the same/similar per-cluster L3 cache from the N1) And in the future they're not able to build >3. German and Leo if there aren't strong objections I think the best path forward is for me to respin these assuming only 3 levels and if someone builds 4 in a far-off-future we can always change the implementation then. Agreed? Thanks, Ali _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel