From: Leo Yan <leo.yan@linaro.org> To: Ali Saidi <alisaidi@amazon.com> Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, german.gomez@arm.com, acme@kernel.org, benh@kernel.crashing.org, Nick.Forrington@arm.com, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, james.clark@arm.com, john.garry@huawei.com, jolsa@kernel.org, kjain@linux.ibm.com, lihuafei1@huawei.com, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH v4 4/4] perf mem: Support HITM for when mem_lvl_num is any Date: Sat, 26 Mar 2022 14:23:03 +0800 [thread overview] Message-ID: <20220326062303.GC20556@leoy-ThinkPad-X240s> (raw) In-Reply-To: <20220324183323.31414-5-alisaidi@amazon.com> On Thu, Mar 24, 2022 at 06:33:23PM +0000, Ali Saidi wrote: > For loads that hit in a the LLC snoop filter and are fulfilled from a > higher level cache on arm64 Neoverse cores, it's not usually clear what > the true level of the cache the data came from (i.e. a transfer from a > core could come from it's L1 or L2). Instead of making an assumption of > where the line came from, add support for incrementing HITM if the > source is CACHE_ANY. > > Since other architectures don't seem to populate the mem_lvl_num field > here there shouldn't be a change in functionality. > > Signed-off-by: Ali Saidi <alisaidi@amazon.com> > Tested-by: German Gomez <german.gomez@arm.com> > Reviewed-by: German Gomez <german.gomez@arm.com> > --- > tools/perf/util/mem-events.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c > index e5e405185498..084977cfebef 100644 > --- a/tools/perf/util/mem-events.c > +++ b/tools/perf/util/mem-events.c > @@ -539,6 +539,15 @@ do { \ > stats->ld_llchit++; > } > > + /* > + * A hit in another cores cache must mean a llc snoop > + * filter hit > + */ > + if (lnum == P(LVLNUM, ANY_CACHE)) { > + if (snoop & P(SNOOP, HITM)) > + HITM_INC(lcl_hitm); > + } This might break the memory profiling result for x86, see file arch/x86/events/intel/ds.c: 97 void __init intel_pmu_pebs_data_source_skl(bool pmem) 98 { 99 u64 pmem_or_l4 = pmem ? LEVEL(PMEM) : LEVEL(L4); ... 105 pebs_data_source[0x0d] = OP_LH | LEVEL(ANY_CACHE) | REM | P(SNOOP, HITM); 106 } Which means that it's possible that it's a remote access and the cache level is ANY_CACHE, it's good to add checking for bit PERF_MEM_REMOTE_REMOTE: u64 remote = data_src->mem_remote; /* * A hit in another cores cache must mean a llc snoop * filter hit */ if (lnum == P(LVLNUM, ANY_CACHE) && remote != P(REMOTE, REMOTE)) { if (snoop & P(SNOOP, HITM)) HITM_INC(lcl_hitm); } Appreciate German's reviewing and testing, and sorry I jumped in very late. Thanks, Leo > + > if (lvl & P(LVL, LOC_RAM) || lnum == P(LVLNUM, RAM)) { > stats->lcl_dram++; > if (snoop & P(SNOOP, HIT)) > -- > 2.32.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org> To: Ali Saidi <alisaidi@amazon.com> Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, german.gomez@arm.com, acme@kernel.org, benh@kernel.crashing.org, Nick.Forrington@arm.com, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, james.clark@arm.com, john.garry@huawei.com, jolsa@kernel.org, kjain@linux.ibm.com, lihuafei1@huawei.com, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH v4 4/4] perf mem: Support HITM for when mem_lvl_num is any Date: Sat, 26 Mar 2022 14:23:03 +0800 [thread overview] Message-ID: <20220326062303.GC20556@leoy-ThinkPad-X240s> (raw) In-Reply-To: <20220324183323.31414-5-alisaidi@amazon.com> On Thu, Mar 24, 2022 at 06:33:23PM +0000, Ali Saidi wrote: > For loads that hit in a the LLC snoop filter and are fulfilled from a > higher level cache on arm64 Neoverse cores, it's not usually clear what > the true level of the cache the data came from (i.e. a transfer from a > core could come from it's L1 or L2). Instead of making an assumption of > where the line came from, add support for incrementing HITM if the > source is CACHE_ANY. > > Since other architectures don't seem to populate the mem_lvl_num field > here there shouldn't be a change in functionality. > > Signed-off-by: Ali Saidi <alisaidi@amazon.com> > Tested-by: German Gomez <german.gomez@arm.com> > Reviewed-by: German Gomez <german.gomez@arm.com> > --- > tools/perf/util/mem-events.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c > index e5e405185498..084977cfebef 100644 > --- a/tools/perf/util/mem-events.c > +++ b/tools/perf/util/mem-events.c > @@ -539,6 +539,15 @@ do { \ > stats->ld_llchit++; > } > > + /* > + * A hit in another cores cache must mean a llc snoop > + * filter hit > + */ > + if (lnum == P(LVLNUM, ANY_CACHE)) { > + if (snoop & P(SNOOP, HITM)) > + HITM_INC(lcl_hitm); > + } This might break the memory profiling result for x86, see file arch/x86/events/intel/ds.c: 97 void __init intel_pmu_pebs_data_source_skl(bool pmem) 98 { 99 u64 pmem_or_l4 = pmem ? LEVEL(PMEM) : LEVEL(L4); ... 105 pebs_data_source[0x0d] = OP_LH | LEVEL(ANY_CACHE) | REM | P(SNOOP, HITM); 106 } Which means that it's possible that it's a remote access and the cache level is ANY_CACHE, it's good to add checking for bit PERF_MEM_REMOTE_REMOTE: u64 remote = data_src->mem_remote; /* * A hit in another cores cache must mean a llc snoop * filter hit */ if (lnum == P(LVLNUM, ANY_CACHE) && remote != P(REMOTE, REMOTE)) { if (snoop & P(SNOOP, HITM)) HITM_INC(lcl_hitm); } Appreciate German's reviewing and testing, and sorry I jumped in very late. Thanks, Leo > + > if (lvl & P(LVL, LOC_RAM) || lnum == P(LVLNUM, RAM)) { > stats->lcl_dram++; > if (snoop & P(SNOOP, HIT)) > -- > 2.32.0 >
next prev parent reply other threads:[~2022-03-26 6:24 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-24 18:33 [PATCH v4 0/4] perf: arm-spe: Decode SPE source and use for perf c2c Ali Saidi 2022-03-24 18:33 ` Ali Saidi 2022-03-24 18:33 ` [PATCH v4 1/4] tools: arm64: Import cputype.h Ali Saidi 2022-03-24 18:33 ` Ali Saidi 2022-03-25 18:39 ` Arnaldo Carvalho de Melo 2022-03-25 18:39 ` Arnaldo Carvalho de Melo 2022-03-25 18:58 ` Ali Saidi 2022-03-25 18:58 ` Ali Saidi 2022-03-25 19:42 ` Arnaldo Carvalho de Melo 2022-03-25 19:42 ` Arnaldo Carvalho de Melo 2022-03-26 5:49 ` Leo Yan 2022-03-26 5:49 ` Leo Yan 2022-03-26 13:59 ` Arnaldo Carvalho de Melo 2022-03-26 13:59 ` Arnaldo Carvalho de Melo 2022-03-24 18:33 ` [PATCH v4 2/4] perf arm-spe: Use SPE data source for neoverse cores Ali Saidi 2022-03-24 18:33 ` Ali Saidi 2022-03-26 13:47 ` Leo Yan 2022-03-26 13:47 ` Leo Yan 2022-03-26 13:52 ` Arnaldo Carvalho de Melo 2022-03-26 13:52 ` Arnaldo Carvalho de Melo 2022-03-26 13:56 ` Leo Yan 2022-03-26 13:56 ` Leo Yan 2022-03-26 14:04 ` Arnaldo Carvalho de Melo 2022-03-26 14:04 ` Arnaldo Carvalho de Melo 2022-03-26 19:43 ` Ali Saidi 2022-03-26 19:43 ` Ali Saidi 2022-03-27 9:09 ` Leo Yan 2022-03-27 9:09 ` Leo Yan 2022-03-28 3:08 ` Ali Saidi 2022-03-28 3:08 ` Ali Saidi 2022-03-28 13:05 ` Leo Yan 2022-03-28 13:05 ` Leo Yan 2022-03-29 13:34 ` Shuai Xue 2022-03-29 13:34 ` Shuai Xue 2022-03-29 14:32 ` Ali Saidi 2022-03-29 14:32 ` Ali Saidi 2022-03-31 12:19 ` Leo Yan 2022-03-31 12:19 ` Leo Yan 2022-03-31 12:28 ` German Gomez 2022-03-31 12:28 ` German Gomez 2022-03-31 12:44 ` Leo Yan 2022-03-31 12:44 ` Leo Yan 2022-04-03 20:33 ` Ali Saidi 2022-04-03 20:33 ` Ali Saidi 2022-04-04 15:12 ` Leo Yan 2022-04-04 15:12 ` Leo Yan 2022-04-06 21:00 ` Ali Saidi 2022-04-06 21:00 ` Ali Saidi 2022-04-08 1:06 ` Leo Yan 2022-04-08 1:06 ` Leo Yan 2022-04-07 15:24 ` German Gomez 2022-04-07 15:24 ` German Gomez 2022-04-08 1:18 ` Leo Yan 2022-04-08 1:18 ` Leo Yan 2022-03-24 18:33 ` [PATCH v4 3/4] perf mem: Support mem_lvl_num in c2c command Ali Saidi 2022-03-24 18:33 ` Ali Saidi 2022-03-26 13:54 ` Arnaldo Carvalho de Melo 2022-03-26 13:54 ` Arnaldo Carvalho de Melo 2022-03-24 18:33 ` [PATCH v4 4/4] perf mem: Support HITM for when mem_lvl_num is any Ali Saidi 2022-03-24 18:33 ` Ali Saidi 2022-03-26 6:23 ` Leo Yan [this message] 2022-03-26 6:23 ` Leo Yan 2022-03-26 13:30 ` Arnaldo Carvalho de Melo 2022-03-26 13:30 ` Arnaldo Carvalho de Melo 2022-03-26 19:14 ` Ali Saidi 2022-03-26 19:14 ` Ali Saidi
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=20220326062303.GC20556@leoy-ThinkPad-X240s \ --to=leo.yan@linaro.org \ --cc=Nick.Forrington@arm.com \ --cc=acme@kernel.org \ --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=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.