From: James Clark <james.clark@linaro.org>
To: Leo Yan <leo.yan@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH 19/25] perf/uapi: Extend data source fields
Date: Thu, 9 Oct 2025 11:00:23 +0100 [thread overview]
Message-ID: <9a5efa8f-f6a6-45c3-954a-bf8c516ac15c@linaro.org> (raw)
In-Reply-To: <20250929-perf_support_arm_spev1-3-v1-19-1150b3c83857@arm.com>
On 29/09/2025 5:37 pm, Leo Yan wrote:
> Arm CPUs introduce several new types of memory operations, like MTE tag
> accessing, system register access for nested virtualization, memcpy &
> memset, and Guarded Control Stack (GCS).
>
> For memory operation details, Arm SPE provides information like data
> (parallel) processing, floating-point, predicated, atomic, exclusive,
> acquire/release, gather/scatter, and conditional.
>
> This commit introduces a field 'mem_op_ext' for extended operation type.
> The extended operation type can be combined with the existed operation
> type to express a memory type, for examples, a PERF_MEM_OP_GCS type can
> be set along with PERF_MEM_OP_LOAD to present a load operation for
> GCS register access.
>
> Also use a field 'mem_aff' to store affiliate information.
>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> include/uapi/linux/perf_event.h | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 78a362b8002776e5ce83a0d7816601638c61ecc6..51ab37d44ac31fcdc4bc919c14d5f97e560d9339 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -1309,14 +1309,18 @@ union perf_mem_data_src {
> mem_snoopx : 2, /* Snoop mode, ext */
> mem_blk : 3, /* Access blocked */
> mem_hops : 3, /* Hop level */
> - mem_rsvd : 18;
> + mem_op_ext : 6, /* Extended type of opcode */
Why have a 6 bit field containing 1 bit per thing when you can have 6
named 1 bit fields? That way you don't have to do a load of bitwise
magic to access it and you don't need separate #defines.
Also, when you set these, you never set more than one bit so they're
exclusive. Would a 3 bit enum be better than a 6 bit bitfield in this case?
> + mem_aff : 8, /* Affiliate info */
> + mem_rsvd : 4;
> };
> };
> #elif defined(__BIG_ENDIAN_BITFIELD)
> union perf_mem_data_src {
> __u64 val;
> struct {
> - __u64 mem_rsvd : 18,
> + __u64 mem_rsvd : 4,
> + mem_aff : 8, /* Affiliate info */
> + mem_op_ext : 6, /* Extended type of opcode */
> mem_hops : 3, /* Hop level */
> mem_blk : 3, /* Access blocked */
> mem_snoopx : 2, /* Snoop mode, ext */
> @@ -1426,6 +1430,26 @@ union perf_mem_data_src {
> /* 5-7 available */
> #define PERF_MEM_HOPS_SHIFT 43
>
> +/* Extended type of memory opcode: */
> +#define PERF_MEM_EXT_OP_MTE_TAG 0x0001 /* MTE tag */
> +#define PERF_MEM_EXT_OP_NESTED_VIRT 0x0002 /* Nested virtualization */
> +#define PERF_MEM_EXT_OP_MEMCPY 0x0004 /* Memory copy */
> +#define PERF_MEM_EXT_OP_MEMSET 0x0008 /* Memory set */
> +#define PERF_MEM_EXT_OP_SIMD 0x0010 /* SIMD */
> +#define PERF_MEM_EXT_OP_GCS 0x0020 /* Guarded Control Stack */
> +#define PERF_MEM_EXT_OP_SHIFT 46
> +
> +/* Affiliate info */
"Affiliate info" doesn't really describe what these are supposed to be,
or why they are separate. Is it implying that they're always set in
addition to another flag? Like "details" or "category"?
Either way, I feel that limitation might be a bit strict for the generic
uapi, or it needs to be described in more detail. If we change this
field to be individual bits like the other one, then maybe we can drop
that it's a separate group and it's just a bunch of bits you can set
however you like.
> +#define PERF_MEM_AFF_DP 0x0001 /* Data processing */
> +#define PERF_MEM_AFF_FP 0x0002 /* Floating-point */
> +#define PERF_MEM_AFF_PRED 0x0004 /* Predicated */
> +#define PERF_MEM_AFF_ATOMIC 0x0008 /* Atomic */
> +#define PERF_MEM_AFF_EXCLUSIVE 0x0010 /* Exclusive */
> +#define PERF_MEM_AFF_AR 0x0020 /* Acquire/release */
> +#define PERF_MEM_AFF_SG 0x0040 /* Gather/Scatter */
> +#define PERF_MEM_AFF_CONDITIONAL 0x0080 /* Conditional */
> +#define PERF_MEM_AFF_SHIFT 52
> +
> #define PERF_MEM_S(a, s) \
> (((__u64)PERF_MEM_##a##_##s) << PERF_MEM_##a##_SHIFT)
>
>
next prev parent reply other threads:[~2025-10-09 10:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 16:37 [PATCH 00/25] perf arm_spe: Extend operations Leo Yan
2025-09-29 16:37 ` [PATCH 01/25] perf arm_spe: Fix memset subclass in operation Leo Yan
2025-09-29 16:37 ` [PATCH 02/25] perf arm_spe: Unify operation naming Leo Yan
2025-09-29 16:37 ` [PATCH 03/25] perf arm_spe: Decode GCS operation Leo Yan
2025-09-29 16:37 ` [PATCH 04/25] perf arm_spe: Rename SPE_OP_PKT_IS_OTHER_SVE_OP macro Leo Yan
2025-09-29 16:37 ` [PATCH 05/25] perf arm_spe: Decode ASE and FP fields in other operation Leo Yan
2025-10-09 9:04 ` James Clark
2025-10-09 9:06 ` James Clark
2025-09-29 16:37 ` [PATCH 06/25] perf arm_spe: Decode SME data processing packet Leo Yan
2025-09-29 16:37 ` [PATCH 07/25] perf arm_spe: Remove unused operation types Leo Yan
2025-09-29 16:37 ` [PATCH 08/25] perf arm_spe: Consolidate " Leo Yan
2025-10-09 9:18 ` James Clark
2025-09-29 16:37 ` [PATCH 09/25] perf arm_spe: Introduce data processing macro for SVE operations Leo Yan
2025-09-29 16:37 ` [PATCH 10/25] perf arm_spe: Report register access in record Leo Yan
2025-09-29 16:37 ` [PATCH 11/25] perf arm_spe: Report MTE allocation tag " Leo Yan
2025-10-09 9:32 ` James Clark
2025-09-29 16:37 ` [PATCH 12/25] perf arm_spe: Report extended memory operations in records Leo Yan
2025-09-29 16:37 ` [PATCH 13/25] perf arm_spe: Report associated info for SVE / SME operations Leo Yan
2025-09-29 16:37 ` [PATCH 14/25] perf arm_spe: Report memset and memcpy in records Leo Yan
2025-10-09 9:33 ` James Clark
2025-09-29 16:37 ` [PATCH 15/25] perf arm_spe: Report GCS in record Leo Yan
2025-09-29 16:37 ` [PATCH 16/25] perf arm_spe: Expose SIMD information in other operations Leo Yan
2025-09-29 16:37 ` [PATCH 17/25] perf arm_spe: Expose length for SVE and SME operations Leo Yan
2025-10-09 9:45 ` James Clark
2025-09-29 16:37 ` [PATCH 18/25] perf arm_spe: Synthesize memory samples for SIMD operations Leo Yan
2025-09-29 16:37 ` [PATCH 19/25] perf/uapi: Extend data source fields Leo Yan
2025-10-09 10:00 ` James Clark [this message]
2025-09-29 16:37 ` [PATCH 20/25] perf mem: Print extended fields Leo Yan
2025-10-09 10:02 ` James Clark
2025-10-09 12:49 ` Arnaldo Carvalho de Melo
2025-09-29 16:37 ` [PATCH 21/25] perf arm_spe: Set extended fields in data source Leo Yan
2025-09-29 16:37 ` [PATCH 22/25] perf sort: Support sort ASE and SME Leo Yan
2025-10-09 10:05 ` James Clark
2025-09-29 16:37 ` [PATCH 23/25] perf sort: Sort disabled and full predicated flags Leo Yan
2025-09-29 16:38 ` [PATCH 24/25] perf report: Update document for SIMD flags Leo Yan
2025-09-29 16:38 ` [PATCH 25/25] perf arm_spe: Improve SIMD flags setting 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=9a5efa8f-f6a6-45c3-954a-bf8c516ac15c@linaro.org \
--to=james.clark@linaro.org \
--cc=acme@kernel.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@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: 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).