From: Leo Yan <leo.yan@arm.com>
To: Yicong Yang <yangyicong@huawei.com>
Cc: James Clark <james.clark@linaro.org>,
yangyicong@hisilicon.com, jonathan.cameron@huawei.com,
hejunhao3@huawei.com, linuxarm@huawei.com,
wangyushan12@huawei.com, caijingtao@huawei.com,
xueshan2@huawei.com, prime.zeng@hisilicon.com, acme@kernel.org,
namhyung@kernel.org, catalin.marinas@arm.com, will@kernel.org,
peterz@infradead.org, mingo@redhat.com, mark.rutland@arm.com,
jolsa@kernel.org, john.g.garry@oracle.com, leo.yan@linux.dev,
irogers@google.com, linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf arm-spe: Add support for SPE Data Source packet on HiSilicon HIP12
Date: Tue, 22 Apr 2025 14:20:06 +0100 [thread overview]
Message-ID: <20250422132006.GG28953@e132581.arm.com> (raw)
In-Reply-To: <ccb8ce65-8241-0670-25c8-f8245fbc5e22@huawei.com>
On Tue, Apr 22, 2025 at 08:31:43PM +0800, Yicong Yang wrote:
[...]
> >>> + case ARM_SPE_HISI_HIP_PEER_CLUSTER:
> >>> + data_src->mem_lvl = PERF_MEM_LVL_REM_CCE1 | PERF_MEM_LVL_HIT;
> >>> + data_src->mem_lvl_num = PERF_MEM_LVLNUM_L3;
> >
> > Seems to me, a CPU has L3 cache, would the cluster has a higher level's
> > cache?
>
> In my case, the cluster CPUs share the L3 cache and there's several clusters.
> L3's the highest level cache in the system.
If so, you might need to revise the cache levels for:
ARM_SPE_HISI_HIP_PEER_CPU
ARM_SPE_HISI_HIP_PEER_CPU_HITM
IIUC, cluster CPUs share L3 cache, and every CPU in a cluster has
L1/L2 cache, for PEER_CPU cases, the memory level should be L2.
[...]
> >>> + case ARM_SPE_HISI_HIP_REMOTE_SOCKET:
> >>> + data_src->mem_lvl = PERF_MEM_LVL_REM_CCE2;
> >>> + data_src->mem_lvl_num = PERF_MEM_LVLNUM_ANY_CACHE;
> >>> + data_src->mem_remote = PERF_MEM_REMOTE_REMOTE;
> >>> + data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
> >>
> >> Hi Yicong,
> >>
> >> Is the mem_snoop setting missing from this one?
> >
> > The field 'mem_snoopx' is an extension to the field 'mem_snoop'.
> >
> > If the field 'mem_snoopx' is set, it is no need to set 'mem_snoop'.
> >
>
> they should not be mutal exclusive. mem_snoopx provides the information where
> the cacheline comes from while mem_snoop provides the status of the cacheline.
> if hardware supports we can gather both information from the data source, like
> above for ARM_SPE_HISI_HIP_PEER_CLUSTER_HITM.
My understanding is the PERF_MEM_SNOOPX_PEER flag was extended for
support Arm SPE. Other snoop flags were original from x86 arch.
I agreed that in some cases above, both the flags PERF_MEM_SNOOPX_PEER
and PERF_MEM_SNOOP_HITM can be set together, you can parse cache sharing
with different --display options:
perf c2c report --display tot => based on HITM flags
perf c2c report --display peer => based on SNOOPX_PEER flag
> for other cases if there's mem_snoopx information I think mem_snoop can be dropped,
> this won't make differeces. Checked c2c_decode_stats(), only PERF_MEM_SNOOP_HIT and
> PERF_MEM_SNOOP_HITM is useful when summarizing c2c statistics.
It is about how to present accurate results.
E.g., for REMOTE_SOCKET type, it is hard to say the data from remote
DRAM or any level's cache. Since more hardware details are absent, this
is why I suggested not to set 'mem_snoop' for REMOTE_SOCKET.
Thanks,
Leo
next prev parent reply other threads:[~2025-04-22 13:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 12:28 [PATCH] perf arm-spe: Add support for SPE Data Source packet on HiSilicon HIP12 Yicong Yang
2025-04-22 9:01 ` Yicong Yang
2025-04-22 9:16 ` James Clark
2025-04-22 10:11 ` Yicong Yang
2025-04-22 10:29 ` Leo Yan
2025-04-22 12:31 ` Yicong Yang
2025-04-22 13:20 ` Leo Yan [this message]
2025-04-23 7:57 ` Yicong Yang
2025-04-24 11:57 ` Yicong Yang
2025-04-24 12:48 ` Leo Yan
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=20250422132006.GG28953@e132581.arm.com \
--to=leo.yan@arm.com \
--cc=acme@kernel.org \
--cc=caijingtao@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=hejunhao3@huawei.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=jonathan.cameron@huawei.com \
--cc=leo.yan@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=prime.zeng@hisilicon.com \
--cc=wangyushan12@huawei.com \
--cc=will@kernel.org \
--cc=xueshan2@huawei.com \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).