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 453AEC433F5 for ; Wed, 6 Apr 2022 21:02:05 +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=8V50stWHi9Et/lOl0cnTx3m6CE4f7Hx/MkCN+v0WuvE=; b=lzWyYSAekjBLJj 0D4P0bhOSPi92K+W1jePwLqPpHaziV8TExCcZjclD9x2xCOxsd8PxEUleHWX+vHGnwynNqv268Vqr +IW/z3/cOXJzlwmFWuWrj2p+FPAPv+RBnSmgOvbVFQyJj+CcjdEjSM4f/U1ylf8W1fbpcyCWlCj8Z JG4jgpNQsi5SKn1TXTmjYVj80cM+xVf5qdmrmSX+sk8g4TLN0pD8OjIjk6y1jq8B8c+f6VgnPsASq XpodCSXFLljIZom4J7NDpCYogANpeWeOcxMCMFAL3DFt9MZtV3xjB6yj74sstqnl/ibAyagkMVq+p ahObRNTdb96udEwG31/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncClj-007wb6-1D; Wed, 06 Apr 2022 21:00:47 +0000 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncCla-007wYn-50 for linux-arm-kernel@lists.infradead.org; Wed, 06 Apr 2022 21:00:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1649278838; x=1680814838; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=S/RUYgJiJDHB7xj8zcZPP8Nba0qoMBr1iDzWuUq4ooM=; b=Dan3806Ni+FsmVGqOk2ARFavKdb0uprpOLdbnoo8YT2AP0HS6zg/KGiX f+rkKEs+/6q+zudkfzzjeCGC7yRxFcosrNMZHP2N0+LRXs+ORqzEPoS5h rarmkkaeB8K35GOzkH+CqC/9W3Q0xzXpKUrTao1h3VIB357hNDdH8NwSF k=; X-IronPort-AV: E=Sophos;i="5.90,240,1643673600"; d="scan'208";a="77373843" Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-iad-1e-54c9d11f.us-east-1.amazon.com) ([10.25.36.214]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP; 06 Apr 2022 21:00:30 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1e-54c9d11f.us-east-1.amazon.com (Postfix) with ESMTPS id BF0E7C0271; Wed, 6 Apr 2022 21:00:24 +0000 (UTC) Received: from EX13D02UWB002.ant.amazon.com (10.43.161.160) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Wed, 6 Apr 2022 21:00:24 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D02UWB002.ant.amazon.com (10.43.161.160) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Wed, 6 Apr 2022 21:00: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.32 via Frontend Transport; Wed, 6 Apr 2022 21:00:23 +0000 Received: by dev-dsk-alisaidi-1d-b9a0e636.us-east-1.amazon.com (Postfix, from userid 5131138) id 134A62510; Wed, 6 Apr 2022 21:00:22 +0000 (UTC) From: Ali Saidi To: CC: , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v4 2/4] perf arm-spe: Use SPE data source for neoverse cores Date: Wed, 6 Apr 2022 21:00:17 +0000 Message-ID: <20220406210017.11887-1-alisaidi@amazon.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20220404151218.GA898573@leoy-ThinkPad-X240s> References: <20220404151218.GA898573@leoy-ThinkPad-X240s> MIME-Version: 1.0 Precedence: Bulk X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220406_140038_283498_9032AC4C X-CRM114-Status: GOOD ( 28.31 ) 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 On Mon, 4 Apr 2022 15:12:18 +0000, Leo Yan wrote: > On Sun, Apr 03, 2022 at 08:33:37PM +0000, Ali Saidi wrote: [...] > > The latter logic is why I think it's perfectly acceptable to use HITM to > > indicate a peer cache-to-cache transfer, however since others don't feel that way > > let me propose a single additional snooping type PERF_MEM_SNOOP_PEER that > > indicates some peer of the hierarchy below the originating core sourced the > > data. This clears up the definition that line came from from a peer and may or > > may not have been modified, but it doesn't add a lot of implementation dependant > > functionality into the SNOOP API. > > > > We could use the mem-level to indicate the level of the cache hierarchy we had > > to get to before the snoop traveled upward, which seems like what x86 is doing > > here. > > It makes sense to me that to use the highest cache level as mem-level. > Please add comments in the code for this, this would be useful for > understanding the code. Ok. > > PEER_CORE -> MEM_SNOOP_PEER + L2 > > PEER_CLSTR -> MEM_SNOOP_PEER + L3 > > PEER_LCL_CLSTR -> MEM_SNOOP_PEER + L3 (since newer neoverse cores don't support > > the clusters and the existing commercial implementations don't have them). > > Generally, this idea is fine for me. Great. Now the next tricky thing. Since we're not using HITM for recording the memory events, the question becomes for the c2c output should we output the SNOOP_PEER events as if they are HITM events with a clarification in the perf-c2c man page or effectively duplicate all the lcl_hitm logic, which is a fair amount, in perf c2c to add a column and sort option? > Following your suggestion, if we connect the concepts PoC and PoU in Arm > reference manual, we can extend the snooping mode with MEM_SNOOP_POU > (for PoU) and MEM_SNOOP_POC (for PoC), so: > > PEER_CORE -> MEM_SNOOP_POU + L2 > PEER_LCL_CLSTR -> MEM_SNOOP_POU + L3 > PEER_CLSTR -> MEM_SNOOP_POC + L3 > > Seems to me, we could consider for this. If this is over complexity or > even I said any wrong concepts for this, please use your method. I think this adds a lot of complexity and reduces clarity. Some systems implement coherent icaches and the PoU would be the L1 cache, others don't so that would be the L2 (or wherever there is a unified cache). Similarly, with the point of coherency, some systems would consider that dram, but other systems have transparent LLCs and it would be the LLC. Thanks, Ali _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel