linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).