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 BE734C433F5 for ; Wed, 27 Apr 2022 17:07:19 +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=1Hn1wOw+ovbGGEHPHum3QTIiLcAn6z7rcCMEDqP/E+w=; b=TxsM0U5c4AoK61 hTd+ynp+dE1Vn4C+9hlTbYQX1dt7kS3+1ZQAM31GJTruXCCnCuzddYepWI8VcJn2l7xlyrgjKUs1N px6bQzmQo9ivt+8hsHgfF5/b371TDYXoKoNOuSJKBOka7vC94t9qsH/uxRSFsZBmaSl9tHVb/6HFA OX5oeLECWWrPfLC4/JoONdDqNhXpnT80+PcGv/FRm20ydN5IesKaHVXkaPit55Djswe5rIT99EuWQ CHTuBS73zLGffbNLCrDHjAyqdt+fdbNugyFUyCf/GvXp8hQogOsFtRy0avdKaHVZI7kLaAjt79EIQ 8dTEJtWIKhSlF2MChhkw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njl76-002WKD-M8; Wed, 27 Apr 2022 17:06:05 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1njkNt-002G0H-FP for linux-arm-kernel@lists.infradead.org; Wed, 27 Apr 2022 16:19:24 +0000 Received: by mail-pl1-x62a.google.com with SMTP id u7so1952473plg.13 for ; Wed, 27 Apr 2022 09:19:19 -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:in-reply-to; bh=fB+D/7pJaYmPUCdn8kycmM+Ul0B8R84B43ZQd5gS8Kc=; b=gIiaVIaQWTRSTYO0iYSxismgtGatUVsnHjsreouyLf2MOb9MUu/wnU4zqgB5cLTxgX ROBO6loS1ZzQ9c3K4+heCtVCySqvO8yulB8m9PzGXIB80JNY8KbbYNf0ippFZ82sA0gW Dfx6gtUdAp38Ae7mwl133SlUtYWxa+MBJe10b8PAcQ8PBooPuOOXu3rz/AEfDEobWEh9 emOr42AABxdRsOegkMJPUEAunHrf8V0foOoeiPEEPC95Uia/bPGuLK0w07ecNtOhrY0W jjW5qiSbK66lahdI3MB20owZwmOdaksuGRcjSywwOeg17cTeppFGSbctYPFk0WMBgaxs Z4lw== 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:in-reply-to; bh=fB+D/7pJaYmPUCdn8kycmM+Ul0B8R84B43ZQd5gS8Kc=; b=RPBUUMLp8AZgTEodRTY1nEDVSgTLD3JmIa4jbo7UNKcc1vlf3+pBf995YNbSKoVS2y xDaAjKZ+7puO4Im//uO+x7b2z9fHH5uTDrliVqX7CKBYQqXz4neZE0xjM4/aZRaXC3TH w/1lMrpkui1A7ygniF5uKiRESJ+mpmC2KRxVTjtDfMvOiD++FgV8DhSjK62TrPkFtMb1 ioYpOu/pzEy7thHfYoJxkk5kckkSDtJXFl2i1/ay3t9DMG8dprVVfsH+ZXEupawzqklI m0QudOnMb4yFschEVM1ZsKwVGEj9NUO9KheJV80arCkn/hZOhE3FncY+D1nO+tfvH1lq 91JQ== X-Gm-Message-State: AOAM533101cYCGs3ghVh4JPt4reH4sksivtPzpQUCmiMKXOQF5hcPSCu 2jxXlMQtA8T9chaJUyIB0qR4fw== X-Google-Smtp-Source: ABdhPJzQQPPVMZgiQeJ7XCwAvPLUZIpex/aF9/4xYQH7aShixtfieF9c2Ptwb0v2h8v8gaVdOZLevg== X-Received: by 2002:a17:902:cec4:b0:15d:50ba:d9bf with SMTP id d4-20020a170902cec400b0015d50bad9bfmr4430492plg.28.1651076358662; Wed, 27 Apr 2022 09:19:18 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([134.195.101.46]) by smtp.gmail.com with ESMTPSA id f10-20020a63de0a000000b003aab55ad590sm17681133pgg.93.2022.04.27.09.19.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 09:19:18 -0700 (PDT) Date: Thu, 28 Apr 2022 00:19:08 +0800 From: Leo Yan To: "Liang, Kan" Cc: Andi Kleen , Ali Saidi , Nick.Forrington@arm.com, acme@kernel.org, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, benh@kernel.crashing.org, german.gomez@arm.com, 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 v5 2/5] perf: Add SNOOP_PEER flag to perf mem data struct Message-ID: <20220427161908.GE562576@leoy-ThinkPad-X240s> References: <20220422212249.22463-1-alisaidi@amazon.com> <20220423063805.GA559531@leoy-ThinkPad-X240s> <8e09af67-a416-4ead-b406-6c8b998de344@linux.intel.com> <20220424114302.GB978927@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-20220427_091921_568589_D2DAAB85 X-CRM114-Status: GOOD ( 27.60 ) 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="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 Kan, On Mon, Apr 25, 2022 at 01:01:40PM -0400, Liang, Kan wrote: > > > On 4/24/2022 7:43 AM, Leo Yan wrote: > > On Sat, Apr 23, 2022 at 05:53:28AM -0700, Andi Kleen wrote: > > > > > > > Except SNOOPX_FWD means a no modified cache snooping, it also means it's > > > > a cache conherency from *remote* socket. This is quite different from we > > > > define SNOOPX_PEER, which only snoop from peer CPU or clusters. > > > > > > The FWD doesn't have to be *remote*. The definition you quoted is just for > the "L3 Miss", which is indeed a remote forward. But we still have > cross-core FWD. See Table 19-101. > > Actually, X86 uses the PERF_MEM_REMOTE_REMOTE + PERF_MEM_SNOOPX_FWD to > indicate the remote FWD, not just SNOOPX_FWD. Thanks a lot for the info. > > > > If no objection, I prefer we could keep the new snoop type SNOOPX_PEER, > > > > this would be easier for us to distinguish the semantics and support the > > > > statistics for SNOOPX_FWD and SNOOPX_PEER separately. > > > > > > > > I overlooked the flag SNOOPX_FWD, thanks a lot for Kan's reminding. > > > > > > Yes seems better to keep using a separate flag if they don't exactly match. > > > > > Yes, I agree with Andi. If you still think the existing flag combination > doesn't match your requirement, a new separate flag should be introduced. > I'm not familiar with ARM. I think I will leave it to you and the maintainer > to decide. It's a bit difficult for me to make decision is because now SNOOPX_FWD is not used in the file util/mem-events.c, so I am not very sure if SNOOPX_FWD has the consistent usage across different arches. On the other hand, I sent a patch for 'peer' flag statistics [1], you could review it and it only stats for L2 and L3 cache level for local node. The main purpose for my sending this email is if you think the FWD can be the consistent for both arches, and even the new added display mode is also useful for x86 arch (we can rename it as 'fwd' display mode), then I am very glad to unify the flag. Thanks, Leo [1] https://lore.kernel.org/lkml/20220427155013.1833222-5-leo.yan@linaro.org/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel