From: "Liang, Kan" <kan.liang@linux.intel.com> To: Leo Yan <leo.yan@linaro.org> Cc: Andi Kleen <ak@linux.intel.com>, Ali Saidi <alisaidi@amazon.com>, 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 Date: Wed, 27 Apr 2022 15:29:31 -0400 [thread overview] Message-ID: <9923422f-2dd3-9951-5814-ab3972e67758@linux.intel.com> (raw) In-Reply-To: <20220427161908.GE562576@leoy-ThinkPad-X240s> On 4/27/2022 12:19 PM, Leo Yan wrote: > 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. No, it's used in the file util/mem-events.c See perf_mem__snp_scnprintf(). > > 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. If it's for the local node, why don't you use the hop level which is introduced recently by Power? The below seems a good fit. PERF_MEM_LVLNUM_ANY_CACHE | PERF_MEM_HOPS_0? /* hop level */ #define PERF_MEM_HOPS_0 0x01 /* remote core, same node */ #define PERF_MEM_HOPS_1 0x02 /* remote node, same socket */ #define PERF_MEM_HOPS_2 0x03 /* remote socket, same board */ #define PERF_MEM_HOPS_3 0x04 /* remote board */ /* 5-7 available */ #define PERF_MEM_HOPS_SHIFT 43 Thanks, Kan > > 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/
WARNING: multiple messages have this Message-ID (diff)
From: "Liang, Kan" <kan.liang@linux.intel.com> To: Leo Yan <leo.yan@linaro.org> Cc: Andi Kleen <ak@linux.intel.com>, Ali Saidi <alisaidi@amazon.com>, 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 Date: Wed, 27 Apr 2022 15:29:31 -0400 [thread overview] Message-ID: <9923422f-2dd3-9951-5814-ab3972e67758@linux.intel.com> (raw) In-Reply-To: <20220427161908.GE562576@leoy-ThinkPad-X240s> On 4/27/2022 12:19 PM, Leo Yan wrote: > 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. No, it's used in the file util/mem-events.c See perf_mem__snp_scnprintf(). > > 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. If it's for the local node, why don't you use the hop level which is introduced recently by Power? The below seems a good fit. PERF_MEM_LVLNUM_ANY_CACHE | PERF_MEM_HOPS_0? /* hop level */ #define PERF_MEM_HOPS_0 0x01 /* remote core, same node */ #define PERF_MEM_HOPS_1 0x02 /* remote node, same socket */ #define PERF_MEM_HOPS_2 0x03 /* remote socket, same board */ #define PERF_MEM_HOPS_3 0x04 /* remote board */ /* 5-7 available */ #define PERF_MEM_HOPS_SHIFT 43 Thanks, Kan > > 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
next prev parent reply other threads:[~2022-04-27 19:30 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-08 19:53 [PATCH v4 0/4] perf: arm-spe: Decode SPE source and use for perf c2c Ali Saidi 2022-04-08 19:53 ` Ali Saidi 2022-04-08 19:53 ` [PATCH v5 1/5] tools: arm64: Import cputype.h Ali Saidi 2022-04-08 19:53 ` Ali Saidi 2022-04-18 14:57 ` Leo Yan 2022-04-18 14:57 ` Leo Yan 2022-04-08 19:53 ` [PATCH v5 2/5] perf: Add SNOOP_PEER flag to perf mem data struct Ali Saidi 2022-04-08 19:53 ` Ali Saidi 2022-04-20 8:20 ` Leo Yan 2022-04-20 8:20 ` Leo Yan 2022-04-20 18:43 ` Liang, Kan 2022-04-20 18:43 ` Liang, Kan 2022-04-22 18:49 ` Ali Saidi 2022-04-22 18:49 ` Ali Saidi 2022-04-22 21:08 ` Liang, Kan 2022-04-22 21:08 ` Liang, Kan 2022-04-22 21:22 ` Ali Saidi 2022-04-22 21:22 ` Ali Saidi 2022-04-23 6:38 ` Leo Yan 2022-04-23 6:38 ` Leo Yan 2022-04-23 12:53 ` Andi Kleen 2022-04-23 12:53 ` Andi Kleen 2022-04-24 11:43 ` Leo Yan 2022-04-24 11:43 ` Leo Yan 2022-04-25 17:01 ` Liang, Kan 2022-04-25 17:01 ` Liang, Kan 2022-04-27 16:19 ` Leo Yan 2022-04-27 16:19 ` Leo Yan 2022-04-27 19:29 ` Liang, Kan [this message] 2022-04-27 19:29 ` Liang, Kan 2022-04-29 9:28 ` Leo Yan 2022-04-29 9:28 ` Leo Yan 2022-04-08 19:53 ` [PATCH v5 3/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER Ali Saidi 2022-04-08 19:53 ` Ali Saidi 2022-04-11 10:26 ` German Gomez 2022-04-11 10:26 ` German Gomez 2022-04-11 14:35 ` German Gomez 2022-04-11 14:35 ` German Gomez 2022-04-20 8:23 ` Leo Yan 2022-04-20 8:23 ` Leo Yan 2022-04-08 19:53 ` [PATCH v5 4/5] perf arm-spe: Use SPE data source for neoverse cores Ali Saidi 2022-04-08 19:53 ` Ali Saidi 2022-04-20 8:30 ` Leo Yan 2022-04-20 8:30 ` Leo Yan 2022-04-20 8:42 ` Leo Yan 2022-04-20 8:42 ` Leo Yan 2022-04-08 19:53 ` [PATCH v5 5/5] perf mem: Support mem_lvl_num in c2c command Ali Saidi 2022-04-08 19:53 ` Ali Saidi 2022-04-11 10:04 ` German Gomez 2022-04-11 10:04 ` German Gomez 2022-04-20 8:48 ` Leo Yan 2022-04-20 8:48 ` Leo Yan 2022-04-20 16:47 ` Arnaldo Carvalho de Melo 2022-04-20 16:47 ` Arnaldo Carvalho de Melo 2022-04-20 19:02 ` Liang, Kan 2022-04-20 19:02 ` Liang, Kan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=9923422f-2dd3-9951-5814-ab3972e67758@linux.intel.com \ --to=kan.liang@linux.intel.com \ --cc=Nick.Forrington@arm.com \ --cc=acme@kernel.org \ --cc=ak@linux.intel.com \ --cc=alexander.shishkin@linux.intel.com \ --cc=alisaidi@amazon.com \ --cc=andrew.kilroy@arm.com \ --cc=benh@kernel.crashing.org \ --cc=german.gomez@arm.com \ --cc=james.clark@arm.com \ --cc=john.garry@huawei.com \ --cc=jolsa@kernel.org \ --cc=kjain@linux.ibm.com \ --cc=leo.yan@linaro.org \ --cc=lihuafei1@huawei.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-perf-users@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mathieu.poirier@linaro.org \ --cc=mingo@redhat.com \ --cc=namhyung@kernel.org \ --cc=peterz@infradead.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.