* [PATCH v8 0/4] perf: arm-spe: Decode SPE source and use for perf c2c
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
When synthesizing data from SPE, augment the type with source information
for Arm Neoverse cores so we can detect situtions like cache line
contention and transfers on Arm platforms.
This changes enables future changes to c2c on a system with SPE where lines that
are shared among multiple cores show up in perf c2c output.
Changes in v8:
* Report NA for both mem_lvl and mem_lvl_num for stores where we have no
information
Changes in v7:
* Minor change requested by Leo Yan
Changes in v6:
* Drop changes to c2c command which will come from Leo Yan
Changes in v5:
* Add a new snooping type to disambiguate cache-to-cache transfers where
we don't know if the data is clean or dirty.
* Set snoop flags on all the data-source cases
* Special case stores as we have no information on them
Changes in v4:
* Bring-in the kernel's arch/arm64/include/asm/cputype.h into tools/
* Add neoverse-v1 to the neoverse cores list
Ali Saidi (4):
tools: arm64: Import cputype.h
perf arm-spe: Use SPE data source for neoverse cores
perf mem: Support mem_lvl_num in c2c command
perf mem: Support HITM for when mem_lvl_num is any
tools/arch/arm64/include/asm/cputype.h | 258 ++++++++++++++++++
.../util/arm-spe-decoder/arm-spe-decoder.c | 1 +
.../util/arm-spe-decoder/arm-spe-decoder.h | 12 +
tools/perf/util/arm-spe.c | 110 +++++++-
tools/perf/util/mem-events.c | 20 +-
5 files changed, 383 insertions(+), 18 deletions(-)
create mode 100644 tools/arch/arm64/include/asm/cputype.h
--
2.32.0
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v8 0/4] perf: arm-spe: Decode SPE source and use for perf c2c
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
When synthesizing data from SPE, augment the type with source information
for Arm Neoverse cores so we can detect situtions like cache line
contention and transfers on Arm platforms.
This changes enables future changes to c2c on a system with SPE where lines that
are shared among multiple cores show up in perf c2c output.
Changes in v8:
* Report NA for both mem_lvl and mem_lvl_num for stores where we have no
information
Changes in v7:
* Minor change requested by Leo Yan
Changes in v6:
* Drop changes to c2c command which will come from Leo Yan
Changes in v5:
* Add a new snooping type to disambiguate cache-to-cache transfers where
we don't know if the data is clean or dirty.
* Set snoop flags on all the data-source cases
* Special case stores as we have no information on them
Changes in v4:
* Bring-in the kernel's arch/arm64/include/asm/cputype.h into tools/
* Add neoverse-v1 to the neoverse cores list
Ali Saidi (4):
tools: arm64: Import cputype.h
perf arm-spe: Use SPE data source for neoverse cores
perf mem: Support mem_lvl_num in c2c command
perf mem: Support HITM for when mem_lvl_num is any
tools/arch/arm64/include/asm/cputype.h | 258 ++++++++++++++++++
.../util/arm-spe-decoder/arm-spe-decoder.c | 1 +
.../util/arm-spe-decoder/arm-spe-decoder.h | 12 +
tools/perf/util/arm-spe.c | 110 +++++++-
tools/perf/util/mem-events.c | 20 +-
5 files changed, 383 insertions(+), 18 deletions(-)
create mode 100644 tools/arch/arm64/include/asm/cputype.h
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-04 18:48 ` Ali Saidi
-1 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Add a flag to the perf mem data struct to signal that a request caused a
cache-to-cache transfer of a line from a peer of the requestor and
wasn't sourced from a lower cache level. The line being moved from one
peer cache to another has latency and performance implications. On Arm64
Neoverse systems the data source can indicate a cache-to-cache transfer
but not if the line is dirty or clean, so instead of overloading HITM
define a new flag that indicates this type of transfer.
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
---
include/uapi/linux/perf_event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index d37629dbad72..7b88bfd097dc 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -1310,7 +1310,7 @@ union perf_mem_data_src {
#define PERF_MEM_SNOOP_SHIFT 19
#define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
-/* 1 free */
+#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
#define PERF_MEM_SNOOPX_SHIFT 38
/* locked instruction */
--
2.32.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Add a flag to the perf mem data struct to signal that a request caused a
cache-to-cache transfer of a line from a peer of the requestor and
wasn't sourced from a lower cache level. The line being moved from one
peer cache to another has latency and performance implications. On Arm64
Neoverse systems the data source can indicate a cache-to-cache transfer
but not if the line is dirty or clean, so instead of overloading HITM
define a new flag that indicates this type of transfer.
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
---
include/uapi/linux/perf_event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index d37629dbad72..7b88bfd097dc 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -1310,7 +1310,7 @@ union perf_mem_data_src {
#define PERF_MEM_SNOOP_SHIFT 19
#define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
-/* 1 free */
+#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
#define PERF_MEM_SNOOPX_SHIFT 38
/* locked instruction */
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-04 18:48 ` Ali Saidi
-1 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Add a flag to the perf mem data struct to signal that a request caused a
cache-to-cache transfer of a line from a peer of the requestor and
wasn't sourced from a lower cache level. The line being moved from one
peer cache to another has latency and performance implications. On Arm64
Neoverse systems the data source can indicate a cache-to-cache transfer
but not if the line is dirty or clean, so instead of overloading HITM
define a new flag that indicates this type of transfer.
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
---
tools/include/uapi/linux/perf_event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
index d37629dbad72..7b88bfd097dc 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -1310,7 +1310,7 @@ union perf_mem_data_src {
#define PERF_MEM_SNOOP_SHIFT 19
#define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
-/* 1 free */
+#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
#define PERF_MEM_SNOOPX_SHIFT 38
/* locked instruction */
--
2.32.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Add a flag to the perf mem data struct to signal that a request caused a
cache-to-cache transfer of a line from a peer of the requestor and
wasn't sourced from a lower cache level. The line being moved from one
peer cache to another has latency and performance implications. On Arm64
Neoverse systems the data source can indicate a cache-to-cache transfer
but not if the line is dirty or clean, so instead of overloading HITM
define a new flag that indicates this type of transfer.
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
---
tools/include/uapi/linux/perf_event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
index d37629dbad72..7b88bfd097dc 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -1310,7 +1310,7 @@ union perf_mem_data_src {
#define PERF_MEM_SNOOP_SHIFT 19
#define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
-/* 1 free */
+#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
#define PERF_MEM_SNOOPX_SHIFT 38
/* locked instruction */
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 3/5] perf mem: Print snoop peer flag
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-04 18:48 ` Ali Saidi
-1 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
From: Leo Yan <leo.yan@linaro.org>
Since PERF_MEM_SNOOPX_PEER flag is a new snoop type, print this flag if
it is set.
Before:
memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
After:
memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Ali Saidi <alisaidi@amazon.com>
Tested-by: Ali Saidi <alisaidi@amazon.com>
---
tools/perf/util/mem-events.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index efaf263464b9..db5225caaabe 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -410,6 +410,11 @@ static const char * const snoop_access[] = {
"HitM",
};
+static const char * const snoopx_access[] = {
+ "Fwd",
+ "Peer",
+};
+
int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
{
size_t i, l = 0;
@@ -430,13 +435,20 @@ int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
}
l += scnprintf(out + l, sz - l, snoop_access[i]);
}
- if (mem_info &&
- (mem_info->data_src.mem_snoopx & PERF_MEM_SNOOPX_FWD)) {
+
+ m = 0;
+ if (mem_info)
+ m = mem_info->data_src.mem_snoopx;
+
+ for (i = 0; m && i < ARRAY_SIZE(snoopx_access); i++, m >>= 1) {
+ if (!(m & 0x1))
+ continue;
+
if (l) {
strcat(out, " or ");
l += 4;
}
- l += scnprintf(out + l, sz - l, "Fwd");
+ l += scnprintf(out + l, sz - l, snoopx_access[i]);
}
if (*out == '\0')
--
2.32.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 3/5] perf mem: Print snoop peer flag
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
From: Leo Yan <leo.yan@linaro.org>
Since PERF_MEM_SNOOPX_PEER flag is a new snoop type, print this flag if
it is set.
Before:
memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
After:
memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Ali Saidi <alisaidi@amazon.com>
Tested-by: Ali Saidi <alisaidi@amazon.com>
---
tools/perf/util/mem-events.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index efaf263464b9..db5225caaabe 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -410,6 +410,11 @@ static const char * const snoop_access[] = {
"HitM",
};
+static const char * const snoopx_access[] = {
+ "Fwd",
+ "Peer",
+};
+
int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
{
size_t i, l = 0;
@@ -430,13 +435,20 @@ int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
}
l += scnprintf(out + l, sz - l, snoop_access[i]);
}
- if (mem_info &&
- (mem_info->data_src.mem_snoopx & PERF_MEM_SNOOPX_FWD)) {
+
+ m = 0;
+ if (mem_info)
+ m = mem_info->data_src.mem_snoopx;
+
+ for (i = 0; m && i < ARRAY_SIZE(snoopx_access); i++, m >>= 1) {
+ if (!(m & 0x1))
+ continue;
+
if (l) {
strcat(out, " or ");
l += 4;
}
- l += scnprintf(out + l, sz - l, "Fwd");
+ l += scnprintf(out + l, sz - l, snoopx_access[i]);
}
if (*out == '\0')
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 4/5] perf arm-spe: Don't set data source if it's not a memory operation
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-04 18:48 ` Ali Saidi
-1 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
From: Leo Yan <leo.yan@linaro.org>
Except memory load and store operations, Arm SPE records also can
support other operation types, bug when set the data source field the
current code assumes a record is a either load operation or store
operation, this leads to wrongly synthesize memory samples.
This patch strictly checks the record operation type, it only sets data
source only for the operation types ARM_SPE_LD and ARM_SPE_ST,
otherwise, returns zero for data source. Therefore, we can synthesize
memory samples only when data source is a non-zero value, the function
arm_spe__is_memory_event() is useless and removed.
Fixes: e55ed3423c1b ("perf arm-spe: Synthesize memory event")
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Ali Saidi <alisaidi@amazon.com>
Tested-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: German Gomez <german.gomez@arm.com>
---
tools/perf/util/arm-spe.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index d2b64e3f588b..e032efc03274 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -387,26 +387,16 @@ static int arm_spe__synth_instruction_sample(struct arm_spe_queue *speq,
return arm_spe_deliver_synth_event(spe, speq, event, &sample);
}
-#define SPE_MEM_TYPE (ARM_SPE_L1D_ACCESS | ARM_SPE_L1D_MISS | \
- ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS | \
- ARM_SPE_REMOTE_ACCESS)
-
-static bool arm_spe__is_memory_event(enum arm_spe_sample_type type)
-{
- if (type & SPE_MEM_TYPE)
- return true;
-
- return false;
-}
-
static u64 arm_spe__synth_data_source(const struct arm_spe_record *record)
{
union perf_mem_data_src data_src = { 0 };
if (record->op == ARM_SPE_LD)
data_src.mem_op = PERF_MEM_OP_LOAD;
- else
+ else if (record->op == ARM_SPE_ST)
data_src.mem_op = PERF_MEM_OP_STORE;
+ else
+ return 0;
if (record->type & (ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS)) {
data_src.mem_lvl = PERF_MEM_LVL_L3;
@@ -510,7 +500,11 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
return err;
}
- if (spe->sample_memory && arm_spe__is_memory_event(record->type)) {
+ /*
+ * When data_src is zero it means the record is not a memory operation,
+ * skip to synthesize memory sample for this case.
+ */
+ if (spe->sample_memory && data_src) {
err = arm_spe__synth_mem_sample(speq, spe->memory_id, data_src);
if (err)
return err;
--
2.32.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 4/5] perf arm-spe: Don't set data source if it's not a memory operation
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
From: Leo Yan <leo.yan@linaro.org>
Except memory load and store operations, Arm SPE records also can
support other operation types, bug when set the data source field the
current code assumes a record is a either load operation or store
operation, this leads to wrongly synthesize memory samples.
This patch strictly checks the record operation type, it only sets data
source only for the operation types ARM_SPE_LD and ARM_SPE_ST,
otherwise, returns zero for data source. Therefore, we can synthesize
memory samples only when data source is a non-zero value, the function
arm_spe__is_memory_event() is useless and removed.
Fixes: e55ed3423c1b ("perf arm-spe: Synthesize memory event")
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Ali Saidi <alisaidi@amazon.com>
Tested-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: German Gomez <german.gomez@arm.com>
---
tools/perf/util/arm-spe.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index d2b64e3f588b..e032efc03274 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -387,26 +387,16 @@ static int arm_spe__synth_instruction_sample(struct arm_spe_queue *speq,
return arm_spe_deliver_synth_event(spe, speq, event, &sample);
}
-#define SPE_MEM_TYPE (ARM_SPE_L1D_ACCESS | ARM_SPE_L1D_MISS | \
- ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS | \
- ARM_SPE_REMOTE_ACCESS)
-
-static bool arm_spe__is_memory_event(enum arm_spe_sample_type type)
-{
- if (type & SPE_MEM_TYPE)
- return true;
-
- return false;
-}
-
static u64 arm_spe__synth_data_source(const struct arm_spe_record *record)
{
union perf_mem_data_src data_src = { 0 };
if (record->op == ARM_SPE_LD)
data_src.mem_op = PERF_MEM_OP_LOAD;
- else
+ else if (record->op == ARM_SPE_ST)
data_src.mem_op = PERF_MEM_OP_STORE;
+ else
+ return 0;
if (record->type & (ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS)) {
data_src.mem_lvl = PERF_MEM_LVL_L3;
@@ -510,7 +500,11 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
return err;
}
- if (spe->sample_memory && arm_spe__is_memory_event(record->type)) {
+ /*
+ * When data_src is zero it means the record is not a memory operation,
+ * skip to synthesize memory sample for this case.
+ */
+ if (spe->sample_memory && data_src) {
err = arm_spe__synth_mem_sample(speq, spe->memory_id, data_src);
if (err)
return err;
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-04 18:48 ` Ali Saidi
-1 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
When synthesizing data from SPE, augment the type with source information
for Arm Neoverse cores. The field is IMPLDEF but the Neoverse cores all use
the same encoding. I can't find encoding information for any other SPE
implementations to unify their choices with Arm's thus that is left for
future work.
This change populates the mem_lvl_num for Neoverse cores as well as the
deprecated mem_lvl namespace.
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: German Gomez <german.gomez@arm.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
---
.../util/arm-spe-decoder/arm-spe-decoder.c | 1 +
.../util/arm-spe-decoder/arm-spe-decoder.h | 12 ++
tools/perf/util/arm-spe.c | 130 +++++++++++++++---
3 files changed, 127 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
index 5e390a1a79ab..091987dd3966 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
@@ -220,6 +220,7 @@ static int arm_spe_read_record(struct arm_spe_decoder *decoder)
break;
case ARM_SPE_DATA_SOURCE:
+ decoder->record.source = payload;
break;
case ARM_SPE_BAD:
break;
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
index 69b31084d6be..46a61df1145b 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
@@ -29,6 +29,17 @@ enum arm_spe_op_type {
ARM_SPE_ST = 1 << 1,
};
+enum arm_spe_neoverse_data_source {
+ ARM_SPE_NV_L1D = 0x0,
+ ARM_SPE_NV_L2 = 0x8,
+ ARM_SPE_NV_PEER_CORE = 0x9,
+ ARM_SPE_NV_LOCAL_CLUSTER = 0xa,
+ ARM_SPE_NV_SYS_CACHE = 0xb,
+ ARM_SPE_NV_PEER_CLUSTER = 0xc,
+ ARM_SPE_NV_REMOTE = 0xd,
+ ARM_SPE_NV_DRAM = 0xe,
+};
+
struct arm_spe_record {
enum arm_spe_sample_type type;
int err;
@@ -40,6 +51,7 @@ struct arm_spe_record {
u64 virt_addr;
u64 phys_addr;
u64 context_id;
+ u16 source;
};
struct arm_spe_insn;
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index e032efc03274..db3bd41a257b 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -34,6 +34,7 @@
#include "arm-spe-decoder/arm-spe-decoder.h"
#include "arm-spe-decoder/arm-spe-pkt-decoder.h"
+#include "../../arch/arm64/include/asm/cputype.h"
#define MAX_TIMESTAMP (~0ULL)
struct arm_spe {
@@ -45,6 +46,7 @@ struct arm_spe {
struct perf_session *session;
struct machine *machine;
u32 pmu_type;
+ u64 midr;
struct perf_tsc_conversion tc;
@@ -387,35 +389,128 @@ static int arm_spe__synth_instruction_sample(struct arm_spe_queue *speq,
return arm_spe_deliver_synth_event(spe, speq, event, &sample);
}
-static u64 arm_spe__synth_data_source(const struct arm_spe_record *record)
+static const struct midr_range neoverse_spe[] = {
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
+ {},
+};
+
+static void arm_spe__synth_data_source_neoverse(const struct arm_spe_record *record,
+ union perf_mem_data_src *data_src)
{
- union perf_mem_data_src data_src = { 0 };
+ /*
+ * Even though four levels of cache hierarchy are possible, no known
+ * production Neoverse systems currently include more than three levels
+ * so for the time being we assume three exist. If a production system
+ * is built with four the this function would have to be changed to
+ * detect the number of levels for reporting.
+ */
- if (record->op == ARM_SPE_LD)
- data_src.mem_op = PERF_MEM_OP_LOAD;
- else if (record->op == ARM_SPE_ST)
- data_src.mem_op = PERF_MEM_OP_STORE;
- else
- return 0;
+ /*
+ * We have no data on the hit level or data source for stores in the
+ * Neoverse SPE records.
+ */
+ if (record->op & ARM_SPE_ST) {
+ data_src->mem_lvl = PERF_MEM_LVL_NA;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_NA;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NA;
+ return;
+ }
+
+ switch (record->source) {
+ case ARM_SPE_NV_L1D:
+ data_src->mem_lvl = PERF_MEM_LVL_L1 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L1;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
+ break;
+ case ARM_SPE_NV_L2:
+ data_src->mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
+ break;
+ case ARM_SPE_NV_PEER_CORE:
+ data_src->mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
+ data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
+ break;
+ /*
+ * We don't know if this is L1, L2 but we do know it was a cache-2-cache
+ * transfer, so set SNOOPX_PEER
+ */
+ case ARM_SPE_NV_LOCAL_CLUSTER:
+ case ARM_SPE_NV_PEER_CLUSTER:
+ data_src->mem_lvl = PERF_MEM_LVL_L3 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L3;
+ data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
+ break;
+ /*
+ * System cache is assumed to be L3
+ */
+ case ARM_SPE_NV_SYS_CACHE:
+ data_src->mem_lvl = PERF_MEM_LVL_L3 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L3;
+ data_src->mem_snoop = PERF_MEM_SNOOP_HIT;
+ break;
+ /*
+ * We don't know what level it hit in, except it came from the other
+ * socket
+ */
+ case ARM_SPE_NV_REMOTE:
+ data_src->mem_lvl = PERF_MEM_LVL_REM_RAM1 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_RAM;
+ data_src->mem_remote = PERF_MEM_REMOTE_REMOTE;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NA;
+ break;
+ case ARM_SPE_NV_DRAM:
+ data_src->mem_lvl = PERF_MEM_LVL_LOC_RAM | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_RAM;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
+ break;
+ default:
+ break;
+ }
+}
+static void arm_spe__synth_data_source_generic(const struct arm_spe_record *record,
+ union perf_mem_data_src *data_src)
+{
if (record->type & (ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS)) {
- data_src.mem_lvl = PERF_MEM_LVL_L3;
+ data_src->mem_lvl = PERF_MEM_LVL_L3;
if (record->type & ARM_SPE_LLC_MISS)
- data_src.mem_lvl |= PERF_MEM_LVL_MISS;
+ data_src->mem_lvl |= PERF_MEM_LVL_MISS;
else
- data_src.mem_lvl |= PERF_MEM_LVL_HIT;
+ data_src->mem_lvl |= PERF_MEM_LVL_HIT;
} else if (record->type & (ARM_SPE_L1D_ACCESS | ARM_SPE_L1D_MISS)) {
- data_src.mem_lvl = PERF_MEM_LVL_L1;
+ data_src->mem_lvl = PERF_MEM_LVL_L1;
if (record->type & ARM_SPE_L1D_MISS)
- data_src.mem_lvl |= PERF_MEM_LVL_MISS;
+ data_src->mem_lvl |= PERF_MEM_LVL_MISS;
else
- data_src.mem_lvl |= PERF_MEM_LVL_HIT;
+ data_src->mem_lvl |= PERF_MEM_LVL_HIT;
}
if (record->type & ARM_SPE_REMOTE_ACCESS)
- data_src.mem_lvl |= PERF_MEM_LVL_REM_CCE1;
+ data_src->mem_lvl |= PERF_MEM_LVL_REM_CCE1;
+}
+
+static u64 arm_spe__synth_data_source(const struct arm_spe_record *record, u64 midr)
+{
+ union perf_mem_data_src data_src = { 0 };
+ bool is_neoverse = is_midr_in_range(midr, neoverse_spe);
+
+ if (record->op == ARM_SPE_LD)
+ data_src.mem_op = PERF_MEM_OP_LOAD;
+ else if (record->op == ARM_SPE_ST)
+ data_src.mem_op = PERF_MEM_OP_STORE;
+ else
+ return 0;
+
+ if (is_neoverse)
+ arm_spe__synth_data_source_neoverse(record, &data_src);
+ else
+ arm_spe__synth_data_source_generic(record, &data_src);
if (record->type & (ARM_SPE_TLB_ACCESS | ARM_SPE_TLB_MISS)) {
data_src.mem_dtlb = PERF_MEM_TLB_WK;
@@ -436,7 +531,7 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
u64 data_src;
int err;
- data_src = arm_spe__synth_data_source(record);
+ data_src = arm_spe__synth_data_source(record, spe->midr);
if (spe->sample_flc) {
if (record->type & ARM_SPE_L1D_MISS) {
@@ -1177,6 +1272,8 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
struct perf_record_auxtrace_info *auxtrace_info = &event->auxtrace_info;
size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
struct perf_record_time_conv *tc = &session->time_conv;
+ const char *cpuid = perf_env__cpuid(session->evlist->env);
+ u64 midr = strtol(cpuid, NULL, 16);
struct arm_spe *spe;
int err;
@@ -1196,6 +1293,7 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
spe->machine = &session->machines.host; /* No kvm support */
spe->auxtrace_type = auxtrace_info->type;
spe->pmu_type = auxtrace_info->priv[ARM_SPE_PMU_TYPE];
+ spe->midr = midr;
spe->timeless_decoding = arm_spe__is_timeless_decoding(spe);
--
2.32.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
@ 2022-05-04 18:48 ` Ali Saidi
0 siblings, 0 replies; 28+ messages in thread
From: Ali Saidi @ 2022-05-04 18:48 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, acme
Cc: alisaidi, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
When synthesizing data from SPE, augment the type with source information
for Arm Neoverse cores. The field is IMPLDEF but the Neoverse cores all use
the same encoding. I can't find encoding information for any other SPE
implementations to unify their choices with Arm's thus that is left for
future work.
This change populates the mem_lvl_num for Neoverse cores as well as the
deprecated mem_lvl namespace.
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Reviewed-by: German Gomez <german.gomez@arm.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
---
.../util/arm-spe-decoder/arm-spe-decoder.c | 1 +
.../util/arm-spe-decoder/arm-spe-decoder.h | 12 ++
tools/perf/util/arm-spe.c | 130 +++++++++++++++---
3 files changed, 127 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
index 5e390a1a79ab..091987dd3966 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
@@ -220,6 +220,7 @@ static int arm_spe_read_record(struct arm_spe_decoder *decoder)
break;
case ARM_SPE_DATA_SOURCE:
+ decoder->record.source = payload;
break;
case ARM_SPE_BAD:
break;
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
index 69b31084d6be..46a61df1145b 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
@@ -29,6 +29,17 @@ enum arm_spe_op_type {
ARM_SPE_ST = 1 << 1,
};
+enum arm_spe_neoverse_data_source {
+ ARM_SPE_NV_L1D = 0x0,
+ ARM_SPE_NV_L2 = 0x8,
+ ARM_SPE_NV_PEER_CORE = 0x9,
+ ARM_SPE_NV_LOCAL_CLUSTER = 0xa,
+ ARM_SPE_NV_SYS_CACHE = 0xb,
+ ARM_SPE_NV_PEER_CLUSTER = 0xc,
+ ARM_SPE_NV_REMOTE = 0xd,
+ ARM_SPE_NV_DRAM = 0xe,
+};
+
struct arm_spe_record {
enum arm_spe_sample_type type;
int err;
@@ -40,6 +51,7 @@ struct arm_spe_record {
u64 virt_addr;
u64 phys_addr;
u64 context_id;
+ u16 source;
};
struct arm_spe_insn;
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index e032efc03274..db3bd41a257b 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -34,6 +34,7 @@
#include "arm-spe-decoder/arm-spe-decoder.h"
#include "arm-spe-decoder/arm-spe-pkt-decoder.h"
+#include "../../arch/arm64/include/asm/cputype.h"
#define MAX_TIMESTAMP (~0ULL)
struct arm_spe {
@@ -45,6 +46,7 @@ struct arm_spe {
struct perf_session *session;
struct machine *machine;
u32 pmu_type;
+ u64 midr;
struct perf_tsc_conversion tc;
@@ -387,35 +389,128 @@ static int arm_spe__synth_instruction_sample(struct arm_spe_queue *speq,
return arm_spe_deliver_synth_event(spe, speq, event, &sample);
}
-static u64 arm_spe__synth_data_source(const struct arm_spe_record *record)
+static const struct midr_range neoverse_spe[] = {
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
+ {},
+};
+
+static void arm_spe__synth_data_source_neoverse(const struct arm_spe_record *record,
+ union perf_mem_data_src *data_src)
{
- union perf_mem_data_src data_src = { 0 };
+ /*
+ * Even though four levels of cache hierarchy are possible, no known
+ * production Neoverse systems currently include more than three levels
+ * so for the time being we assume three exist. If a production system
+ * is built with four the this function would have to be changed to
+ * detect the number of levels for reporting.
+ */
- if (record->op == ARM_SPE_LD)
- data_src.mem_op = PERF_MEM_OP_LOAD;
- else if (record->op == ARM_SPE_ST)
- data_src.mem_op = PERF_MEM_OP_STORE;
- else
- return 0;
+ /*
+ * We have no data on the hit level or data source for stores in the
+ * Neoverse SPE records.
+ */
+ if (record->op & ARM_SPE_ST) {
+ data_src->mem_lvl = PERF_MEM_LVL_NA;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_NA;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NA;
+ return;
+ }
+
+ switch (record->source) {
+ case ARM_SPE_NV_L1D:
+ data_src->mem_lvl = PERF_MEM_LVL_L1 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L1;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
+ break;
+ case ARM_SPE_NV_L2:
+ data_src->mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
+ break;
+ case ARM_SPE_NV_PEER_CORE:
+ data_src->mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
+ data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
+ break;
+ /*
+ * We don't know if this is L1, L2 but we do know it was a cache-2-cache
+ * transfer, so set SNOOPX_PEER
+ */
+ case ARM_SPE_NV_LOCAL_CLUSTER:
+ case ARM_SPE_NV_PEER_CLUSTER:
+ data_src->mem_lvl = PERF_MEM_LVL_L3 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L3;
+ data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
+ break;
+ /*
+ * System cache is assumed to be L3
+ */
+ case ARM_SPE_NV_SYS_CACHE:
+ data_src->mem_lvl = PERF_MEM_LVL_L3 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_L3;
+ data_src->mem_snoop = PERF_MEM_SNOOP_HIT;
+ break;
+ /*
+ * We don't know what level it hit in, except it came from the other
+ * socket
+ */
+ case ARM_SPE_NV_REMOTE:
+ data_src->mem_lvl = PERF_MEM_LVL_REM_RAM1 | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_RAM;
+ data_src->mem_remote = PERF_MEM_REMOTE_REMOTE;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NA;
+ break;
+ case ARM_SPE_NV_DRAM:
+ data_src->mem_lvl = PERF_MEM_LVL_LOC_RAM | PERF_MEM_LVL_HIT;
+ data_src->mem_lvl_num = PERF_MEM_LVLNUM_RAM;
+ data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
+ break;
+ default:
+ break;
+ }
+}
+static void arm_spe__synth_data_source_generic(const struct arm_spe_record *record,
+ union perf_mem_data_src *data_src)
+{
if (record->type & (ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS)) {
- data_src.mem_lvl = PERF_MEM_LVL_L3;
+ data_src->mem_lvl = PERF_MEM_LVL_L3;
if (record->type & ARM_SPE_LLC_MISS)
- data_src.mem_lvl |= PERF_MEM_LVL_MISS;
+ data_src->mem_lvl |= PERF_MEM_LVL_MISS;
else
- data_src.mem_lvl |= PERF_MEM_LVL_HIT;
+ data_src->mem_lvl |= PERF_MEM_LVL_HIT;
} else if (record->type & (ARM_SPE_L1D_ACCESS | ARM_SPE_L1D_MISS)) {
- data_src.mem_lvl = PERF_MEM_LVL_L1;
+ data_src->mem_lvl = PERF_MEM_LVL_L1;
if (record->type & ARM_SPE_L1D_MISS)
- data_src.mem_lvl |= PERF_MEM_LVL_MISS;
+ data_src->mem_lvl |= PERF_MEM_LVL_MISS;
else
- data_src.mem_lvl |= PERF_MEM_LVL_HIT;
+ data_src->mem_lvl |= PERF_MEM_LVL_HIT;
}
if (record->type & ARM_SPE_REMOTE_ACCESS)
- data_src.mem_lvl |= PERF_MEM_LVL_REM_CCE1;
+ data_src->mem_lvl |= PERF_MEM_LVL_REM_CCE1;
+}
+
+static u64 arm_spe__synth_data_source(const struct arm_spe_record *record, u64 midr)
+{
+ union perf_mem_data_src data_src = { 0 };
+ bool is_neoverse = is_midr_in_range(midr, neoverse_spe);
+
+ if (record->op == ARM_SPE_LD)
+ data_src.mem_op = PERF_MEM_OP_LOAD;
+ else if (record->op == ARM_SPE_ST)
+ data_src.mem_op = PERF_MEM_OP_STORE;
+ else
+ return 0;
+
+ if (is_neoverse)
+ arm_spe__synth_data_source_neoverse(record, &data_src);
+ else
+ arm_spe__synth_data_source_generic(record, &data_src);
if (record->type & (ARM_SPE_TLB_ACCESS | ARM_SPE_TLB_MISS)) {
data_src.mem_dtlb = PERF_MEM_TLB_WK;
@@ -436,7 +531,7 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
u64 data_src;
int err;
- data_src = arm_spe__synth_data_source(record);
+ data_src = arm_spe__synth_data_source(record, spe->midr);
if (spe->sample_flc) {
if (record->type & ARM_SPE_L1D_MISS) {
@@ -1177,6 +1272,8 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
struct perf_record_auxtrace_info *auxtrace_info = &event->auxtrace_info;
size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
struct perf_record_time_conv *tc = &session->time_conv;
+ const char *cpuid = perf_env__cpuid(session->evlist->env);
+ u64 midr = strtol(cpuid, NULL, 16);
struct arm_spe *spe;
int err;
@@ -1196,6 +1293,7 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
spe->machine = &session->machines.host; /* No kvm support */
spe->auxtrace_type = auxtrace_info->type;
spe->pmu_type = auxtrace_info->priv[ARM_SPE_PMU_TYPE];
+ spe->midr = midr;
spe->timeless_decoding = arm_spe__is_timeless_decoding(spe);
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-05 15:03 ` Leo Yan
-1 siblings, 0 replies; 28+ messages in thread
From: Leo Yan @ 2022-05-05 15:03 UTC (permalink / raw)
To: Ali Saidi
Cc: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
acme, benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, kjain, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On Wed, May 04, 2022 at 06:48:50PM +0000, Ali Saidi wrote:
> When synthesizing data from SPE, augment the type with source information
> for Arm Neoverse cores. The field is IMPLDEF but the Neoverse cores all use
> the same encoding. I can't find encoding information for any other SPE
> implementations to unify their choices with Arm's thus that is left for
> future work.
>
> This change populates the mem_lvl_num for Neoverse cores as well as the
> deprecated mem_lvl namespace.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: German Gomez <german.gomez@arm.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> Tested-by: Leo Yan <leo.yan@linaro.org>
Thanks for updating, Ali. It looks good to me.
Since the store operations have been set as PERF_MEM_LVL_NA and
PERF_MEM_LVLNUM_NA, this is right thing for me, I will update perf c2c
patch set for statistics of store operations with PERF_MEM_LVL_NA.
Thanks,
Leo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
@ 2022-05-05 15:03 ` Leo Yan
0 siblings, 0 replies; 28+ messages in thread
From: Leo Yan @ 2022-05-05 15:03 UTC (permalink / raw)
To: Ali Saidi
Cc: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
acme, benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, kjain, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On Wed, May 04, 2022 at 06:48:50PM +0000, Ali Saidi wrote:
> When synthesizing data from SPE, augment the type with source information
> for Arm Neoverse cores. The field is IMPLDEF but the Neoverse cores all use
> the same encoding. I can't find encoding information for any other SPE
> implementations to unify their choices with Arm's thus that is left for
> future work.
>
> This change populates the mem_lvl_num for Neoverse cores as well as the
> deprecated mem_lvl namespace.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: German Gomez <german.gomez@arm.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> Tested-by: Leo Yan <leo.yan@linaro.org>
Thanks for updating, Ali. It looks good to me.
Since the store operations have been set as PERF_MEM_LVL_NA and
PERF_MEM_LVLNUM_NA, this is right thing for me, I will update perf c2c
patch set for statistics of store operations with PERF_MEM_LVL_NA.
Thanks,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-10 16:28 ` Arnaldo Carvalho de Melo
-1 siblings, 0 replies; 28+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-05-10 16:28 UTC (permalink / raw)
To: Ali Saidi
Cc: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> Add a flag to the perf mem data struct to signal that a request caused a
> cache-to-cache transfer of a line from a peer of the requestor and
> wasn't sourced from a lower cache level. The line being moved from one
> peer cache to another has latency and performance implications. On Arm64
> Neoverse systems the data source can indicate a cache-to-cache transfer
> but not if the line is dirty or clean, so instead of overloading HITM
> define a new flag that indicates this type of transfer.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
Was this already merged on the ARM kernel tree?
- Arnaldo
> ---
> tools/include/uapi/linux/perf_event.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
> index d37629dbad72..7b88bfd097dc 100644
> --- a/tools/include/uapi/linux/perf_event.h
> +++ b/tools/include/uapi/linux/perf_event.h
> @@ -1310,7 +1310,7 @@ union perf_mem_data_src {
> #define PERF_MEM_SNOOP_SHIFT 19
>
> #define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
> -/* 1 free */
> +#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
> #define PERF_MEM_SNOOPX_SHIFT 38
>
> /* locked instruction */
> --
> 2.32.0
--
- Arnaldo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
@ 2022-05-10 16:28 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 28+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-05-10 16:28 UTC (permalink / raw)
To: Ali Saidi
Cc: linux-kernel, linux-perf-users, linux-arm-kernel, german.gomez,
leo.yan, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> Add a flag to the perf mem data struct to signal that a request caused a
> cache-to-cache transfer of a line from a peer of the requestor and
> wasn't sourced from a lower cache level. The line being moved from one
> peer cache to another has latency and performance implications. On Arm64
> Neoverse systems the data source can indicate a cache-to-cache transfer
> but not if the line is dirty or clean, so instead of overloading HITM
> define a new flag that indicates this type of transfer.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
Was this already merged on the ARM kernel tree?
- Arnaldo
> ---
> tools/include/uapi/linux/perf_event.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
> index d37629dbad72..7b88bfd097dc 100644
> --- a/tools/include/uapi/linux/perf_event.h
> +++ b/tools/include/uapi/linux/perf_event.h
> @@ -1310,7 +1310,7 @@ union perf_mem_data_src {
> #define PERF_MEM_SNOOP_SHIFT 19
>
> #define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
> -/* 1 free */
> +#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
> #define PERF_MEM_SNOOPX_SHIFT 38
>
> /* locked instruction */
> --
> 2.32.0
--
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
2022-05-10 16:28 ` Arnaldo Carvalho de Melo
@ 2022-05-11 2:20 ` Leo Yan
-1 siblings, 0 replies; 28+ messages in thread
From: Leo Yan @ 2022-05-11 2:20 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
On Tue, May 10, 2022 at 01:28:38PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> > Add a flag to the perf mem data struct to signal that a request caused a
> > cache-to-cache transfer of a line from a peer of the requestor and
> > wasn't sourced from a lower cache level. The line being moved from one
> > peer cache to another has latency and performance implications. On Arm64
> > Neoverse systems the data source can indicate a cache-to-cache transfer
> > but not if the line is dirty or clean, so instead of overloading HITM
> > define a new flag that indicates this type of transfer.
> >
> > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > Reviewed-by: Leo Yan <leo.yan@linaro.org>
>
> Was this already merged on the ARM kernel tree?
No, I don't think this patch has been merged on Arm kernel tree. I searched
Arm and Arm64 git repos, none of them has merged this patch.
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?qt=author&q=Ali+Saidi
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?qt=author&q=Ali+Saidi
P.s. Ali missed to include German's review tag, see:
https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
Do you want us to resend the patch set for adding tags?
Thanks,
Leo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
@ 2022-05-11 2:20 ` Leo Yan
0 siblings, 0 replies; 28+ messages in thread
From: Leo Yan @ 2022-05-11 2:20 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
On Tue, May 10, 2022 at 01:28:38PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> > Add a flag to the perf mem data struct to signal that a request caused a
> > cache-to-cache transfer of a line from a peer of the requestor and
> > wasn't sourced from a lower cache level. The line being moved from one
> > peer cache to another has latency and performance implications. On Arm64
> > Neoverse systems the data source can indicate a cache-to-cache transfer
> > but not if the line is dirty or clean, so instead of overloading HITM
> > define a new flag that indicates this type of transfer.
> >
> > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > Reviewed-by: Leo Yan <leo.yan@linaro.org>
>
> Was this already merged on the ARM kernel tree?
No, I don't think this patch has been merged on Arm kernel tree. I searched
Arm and Arm64 git repos, none of them has merged this patch.
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?qt=author&q=Ali+Saidi
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?qt=author&q=Ali+Saidi
P.s. Ali missed to include German's review tag, see:
https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
Do you want us to resend the patch set for adding tags?
Thanks,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-11 5:41 ` kajoljain
-1 siblings, 0 replies; 28+ messages in thread
From: kajoljain @ 2022-05-11 5:41 UTC (permalink / raw)
To: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, leo.yan, acme
Cc: benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On 5/5/22 00:18, Ali Saidi wrote:
> Add a flag to the perf mem data struct to signal that a request caused a
> cache-to-cache transfer of a line from a peer of the requestor and
> wasn't sourced from a lower cache level. The line being moved from one
> peer cache to another has latency and performance implications. On Arm64
> Neoverse systems the data source can indicate a cache-to-cache transfer
> but not if the line is dirty or clean, so instead of overloading HITM
> define a new flag that indicates this type of transfer.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> ---
> include/uapi/linux/perf_event.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index d37629dbad72..7b88bfd097dc 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -1310,7 +1310,7 @@ union perf_mem_data_src {
> #define PERF_MEM_SNOOP_SHIFT 19
>
> #define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
> -/* 1 free */
> +#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
> #define PERF_MEM_SNOOPX_SHIFT 38
>
> /* locked instruction */
Patch looks good to me.
Reviewed-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct
@ 2022-05-11 5:41 ` kajoljain
0 siblings, 0 replies; 28+ messages in thread
From: kajoljain @ 2022-05-11 5:41 UTC (permalink / raw)
To: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, leo.yan, acme
Cc: benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On 5/5/22 00:18, Ali Saidi wrote:
> Add a flag to the perf mem data struct to signal that a request caused a
> cache-to-cache transfer of a line from a peer of the requestor and
> wasn't sourced from a lower cache level. The line being moved from one
> peer cache to another has latency and performance implications. On Arm64
> Neoverse systems the data source can indicate a cache-to-cache transfer
> but not if the line is dirty or clean, so instead of overloading HITM
> define a new flag that indicates this type of transfer.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> ---
> include/uapi/linux/perf_event.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index d37629dbad72..7b88bfd097dc 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -1310,7 +1310,7 @@ union perf_mem_data_src {
> #define PERF_MEM_SNOOP_SHIFT 19
>
> #define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
> -/* 1 free */
> +#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
> #define PERF_MEM_SNOOPX_SHIFT 38
>
> /* locked instruction */
Patch looks good to me.
Reviewed-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-11 5:42 ` kajoljain
-1 siblings, 0 replies; 28+ messages in thread
From: kajoljain @ 2022-05-11 5:42 UTC (permalink / raw)
To: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, leo.yan, acme
Cc: benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On 5/5/22 00:18, Ali Saidi wrote:
> Add a flag to the perf mem data struct to signal that a request caused a
> cache-to-cache transfer of a line from a peer of the requestor and
> wasn't sourced from a lower cache level. The line being moved from one
> peer cache to another has latency and performance implications. On Arm64
> Neoverse systems the data source can indicate a cache-to-cache transfer
> but not if the line is dirty or clean, so instead of overloading HITM
> define a new flag that indicates this type of transfer.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/include/uapi/linux/perf_event.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
> index d37629dbad72..7b88bfd097dc 100644
> --- a/tools/include/uapi/linux/perf_event.h
> +++ b/tools/include/uapi/linux/perf_event.h
> @@ -1310,7 +1310,7 @@ union perf_mem_data_src {
> #define PERF_MEM_SNOOP_SHIFT 19
>
> #define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
> -/* 1 free */
> +#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
> #define PERF_MEM_SNOOPX_SHIFT 38
>
> /* locked instruction */
Patch looks good to me.
Reviewed-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
@ 2022-05-11 5:42 ` kajoljain
0 siblings, 0 replies; 28+ messages in thread
From: kajoljain @ 2022-05-11 5:42 UTC (permalink / raw)
To: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, leo.yan, acme
Cc: benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On 5/5/22 00:18, Ali Saidi wrote:
> Add a flag to the perf mem data struct to signal that a request caused a
> cache-to-cache transfer of a line from a peer of the requestor and
> wasn't sourced from a lower cache level. The line being moved from one
> peer cache to another has latency and performance implications. On Arm64
> Neoverse systems the data source can indicate a cache-to-cache transfer
> but not if the line is dirty or clean, so instead of overloading HITM
> define a new flag that indicates this type of transfer.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/include/uapi/linux/perf_event.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
> index d37629dbad72..7b88bfd097dc 100644
> --- a/tools/include/uapi/linux/perf_event.h
> +++ b/tools/include/uapi/linux/perf_event.h
> @@ -1310,7 +1310,7 @@ union perf_mem_data_src {
> #define PERF_MEM_SNOOP_SHIFT 19
>
> #define PERF_MEM_SNOOPX_FWD 0x01 /* forward */
> -/* 1 free */
> +#define PERF_MEM_SNOOPX_PEER 0x02 /* xfer from peer */
> #define PERF_MEM_SNOOPX_SHIFT 38
>
> /* locked instruction */
Patch looks good to me.
Reviewed-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 3/5] perf mem: Print snoop peer flag
2022-05-04 18:48 ` Ali Saidi
@ 2022-05-11 5:45 ` kajoljain
-1 siblings, 0 replies; 28+ messages in thread
From: kajoljain @ 2022-05-11 5:45 UTC (permalink / raw)
To: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, leo.yan, acme
Cc: benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On 5/5/22 00:18, Ali Saidi wrote:
> From: Leo Yan <leo.yan@linaro.org>
>
> Since PERF_MEM_SNOOPX_PEER flag is a new snoop type, print this flag if
> it is set.
>
> Before:
> memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
>
> After:
>
> memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> Reviewed-by: Ali Saidi <alisaidi@amazon.com>
> Tested-by: Ali Saidi <alisaidi@amazon.com>
Patch looks good to me.
Reviewed-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
> ---
> tools/perf/util/mem-events.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index efaf263464b9..db5225caaabe 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -410,6 +410,11 @@ static const char * const snoop_access[] = {
> "HitM",
> };
>
> +static const char * const snoopx_access[] = {
> + "Fwd",
> + "Peer",
> +};
> +
> int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
> {
> size_t i, l = 0;
> @@ -430,13 +435,20 @@ int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
> }
> l += scnprintf(out + l, sz - l, snoop_access[i]);
> }
> - if (mem_info &&
> - (mem_info->data_src.mem_snoopx & PERF_MEM_SNOOPX_FWD)) {
> +
> + m = 0;
> + if (mem_info)
> + m = mem_info->data_src.mem_snoopx;
> +
> + for (i = 0; m && i < ARRAY_SIZE(snoopx_access); i++, m >>= 1) {
> + if (!(m & 0x1))
> + continue;
> +
> if (l) {
> strcat(out, " or ");
> l += 4;
> }
> - l += scnprintf(out + l, sz - l, "Fwd");
> + l += scnprintf(out + l, sz - l, snoopx_access[i]);
> }
>
> if (*out == '\0')
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 3/5] perf mem: Print snoop peer flag
@ 2022-05-11 5:45 ` kajoljain
0 siblings, 0 replies; 28+ messages in thread
From: kajoljain @ 2022-05-11 5:45 UTC (permalink / raw)
To: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, leo.yan, acme
Cc: benh, Nick.Forrington, alexander.shishkin, andrew.kilroy,
james.clark, john.garry, jolsa, lihuafei1, mark.rutland,
mathieu.poirier, mingo, namhyung, peterz, will
On 5/5/22 00:18, Ali Saidi wrote:
> From: Leo Yan <leo.yan@linaro.org>
>
> Since PERF_MEM_SNOOPX_PEER flag is a new snoop type, print this flag if
> it is set.
>
> Before:
> memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP N/A|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
>
> After:
>
> memstress 3603 [020] 122.463754: 1 l1d-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 l1d-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-miss: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 llc-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 tlb-access: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
> memstress 3603 [020] 122.463754: 1 memory: 8688000842 |OP LOAD|LVL L3 or L3 hit|SNP Peer|TLB Walker hit|LCK No|BLK N/A aaaac17c3e88 [unknown] (/home/ubuntu/memstress)
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> Reviewed-by: Ali Saidi <alisaidi@amazon.com>
> Tested-by: Ali Saidi <alisaidi@amazon.com>
Patch looks good to me.
Reviewed-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
> ---
> tools/perf/util/mem-events.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index efaf263464b9..db5225caaabe 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -410,6 +410,11 @@ static const char * const snoop_access[] = {
> "HitM",
> };
>
> +static const char * const snoopx_access[] = {
> + "Fwd",
> + "Peer",
> +};
> +
> int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
> {
> size_t i, l = 0;
> @@ -430,13 +435,20 @@ int perf_mem__snp_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
> }
> l += scnprintf(out + l, sz - l, snoop_access[i]);
> }
> - if (mem_info &&
> - (mem_info->data_src.mem_snoopx & PERF_MEM_SNOOPX_FWD)) {
> +
> + m = 0;
> + if (mem_info)
> + m = mem_info->data_src.mem_snoopx;
> +
> + for (i = 0; m && i < ARRAY_SIZE(snoopx_access); i++, m >>= 1) {
> + if (!(m & 0x1))
> + continue;
> +
> if (l) {
> strcat(out, " or ");
> l += 4;
> }
> - l += scnprintf(out + l, sz - l, "Fwd");
> + l += scnprintf(out + l, sz - l, snoopx_access[i]);
> }
>
> if (*out == '\0')
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
2022-05-11 2:20 ` Leo Yan
@ 2022-05-11 18:28 ` Arnaldo Carvalho de Melo
-1 siblings, 0 replies; 28+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-05-11 18:28 UTC (permalink / raw)
To: Leo Yan
Cc: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Em Wed, May 11, 2022 at 10:20:04AM +0800, Leo Yan escreveu:
> On Tue, May 10, 2022 at 01:28:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> > > Add a flag to the perf mem data struct to signal that a request caused a
> > > cache-to-cache transfer of a line from a peer of the requestor and
> > > wasn't sourced from a lower cache level. The line being moved from one
> > > peer cache to another has latency and performance implications. On Arm64
> > > Neoverse systems the data source can indicate a cache-to-cache transfer
> > > but not if the line is dirty or clean, so instead of overloading HITM
> > > define a new flag that indicates this type of transfer.
> > >
> > > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > > Reviewed-by: Leo Yan <leo.yan@linaro.org>
> >
> > Was this already merged on the ARM kernel tree?
>
> No, I don't think this patch has been merged on Arm kernel tree. I searched
> Arm and Arm64 git repos, none of them has merged this patch.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?qt=author&q=Ali+Saidi
> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?qt=author&q=Ali+Saidi
>
> P.s. Ali missed to include German's review tag, see:
> https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
>
> Do you want us to resend the patch set for adding tags?
I use b4 and it should collect Reviewed-by, Acked-by, etc tags, for
instance, if I use the message-id in your message:
⬢[acme@toolbox perf]$ b4 am -ctsl --cc-trailers 20220511022004.GA956170@leoy-ThinkPad-X240s
Looking up https://lore.kernel.org/r/20220511022004.GA956170%40leoy-ThinkPad-X240s
Grabbing thread from lore.kernel.org/all/20220511022004.GA956170%40leoy-ThinkPad-X240s/t.mbox.gz
Checking for newer revisions on https://lore.kernel.org/all/
Analyzing 12 messages in the thread
Checking attestation on all messages, may take a moment...
---
✓ [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct
+ Reviewed-By: Kajol Jain<kjain@linux.ibm.com> (✓ DKIM/ibm.com)
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-2-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: german.gomez@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
+ Reviewed-By: Kajol Jain<kjain@linux.ibm.com> (✓ DKIM/ibm.com)
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-3-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: german.gomez@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 3/5] perf mem: Print snoop peer flag
+ Reviewed-By: Kajol Jain<kjain@linux.ibm.com> (✓ DKIM/ibm.com)
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-4-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: german.gomez@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 4/5] perf arm-spe: Don't set data source if it's not a memory operation
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-5-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: kjain@linux.ibm.com
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-6-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: kjain@linux.ibm.com
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
---
✓ Signed: DKIM/amazon.com
---
Total patches: 5
---
Cover: ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.cover
Link: https://lore.kernel.org/r/20220504184850.24986-1-alisaidi@amazon.com
Base: not specified
git am ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.mbx
⬢[acme@toolbox perf]$
Somehow it is not being collected... :-\
Not even when I use:
> P.s. Ali missed to include German's review tag, see:
> https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com
Will try updating b4...
- Arnaldo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
@ 2022-05-11 18:28 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 28+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-05-11 18:28 UTC (permalink / raw)
To: Leo Yan
Cc: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Em Wed, May 11, 2022 at 10:20:04AM +0800, Leo Yan escreveu:
> On Tue, May 10, 2022 at 01:28:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> > > Add a flag to the perf mem data struct to signal that a request caused a
> > > cache-to-cache transfer of a line from a peer of the requestor and
> > > wasn't sourced from a lower cache level. The line being moved from one
> > > peer cache to another has latency and performance implications. On Arm64
> > > Neoverse systems the data source can indicate a cache-to-cache transfer
> > > but not if the line is dirty or clean, so instead of overloading HITM
> > > define a new flag that indicates this type of transfer.
> > >
> > > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > > Reviewed-by: Leo Yan <leo.yan@linaro.org>
> >
> > Was this already merged on the ARM kernel tree?
>
> No, I don't think this patch has been merged on Arm kernel tree. I searched
> Arm and Arm64 git repos, none of them has merged this patch.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?qt=author&q=Ali+Saidi
> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?qt=author&q=Ali+Saidi
>
> P.s. Ali missed to include German's review tag, see:
> https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
>
> Do you want us to resend the patch set for adding tags?
I use b4 and it should collect Reviewed-by, Acked-by, etc tags, for
instance, if I use the message-id in your message:
⬢[acme@toolbox perf]$ b4 am -ctsl --cc-trailers 20220511022004.GA956170@leoy-ThinkPad-X240s
Looking up https://lore.kernel.org/r/20220511022004.GA956170%40leoy-ThinkPad-X240s
Grabbing thread from lore.kernel.org/all/20220511022004.GA956170%40leoy-ThinkPad-X240s/t.mbox.gz
Checking for newer revisions on https://lore.kernel.org/all/
Analyzing 12 messages in the thread
Checking attestation on all messages, may take a moment...
---
✓ [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct
+ Reviewed-By: Kajol Jain<kjain@linux.ibm.com> (✓ DKIM/ibm.com)
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-2-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: german.gomez@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
+ Reviewed-By: Kajol Jain<kjain@linux.ibm.com> (✓ DKIM/ibm.com)
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-3-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: german.gomez@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 3/5] perf mem: Print snoop peer flag
+ Reviewed-By: Kajol Jain<kjain@linux.ibm.com> (✓ DKIM/ibm.com)
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-4-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: german.gomez@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 4/5] perf arm-spe: Don't set data source if it's not a memory operation
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-5-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: kjain@linux.ibm.com
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
✓ [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
+ Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+ Link: https://lore.kernel.org/r/20220504184850.24986-6-alisaidi@amazon.com
+ Cc: Nick.Forrington@arm.com
+ Cc: andrew.kilroy@arm.com
+ Cc: james.clark@arm.com
+ Cc: mark.rutland@arm.com
+ Cc: john.garry@huawei.com
+ Cc: lihuafei1@huawei.com
+ Cc: peterz@infradead.org
+ Cc: benh@kernel.crashing.org
+ Cc: acme@kernel.org
+ Cc: jolsa@kernel.org
+ Cc: namhyung@kernel.org
+ Cc: will@kernel.org
+ Cc: mathieu.poirier@linaro.org
+ Cc: kjain@linux.ibm.com
+ Cc: alexander.shishkin@linux.intel.com
+ Cc: linux-arm-kernel@lists.infradead.org
+ Cc: mingo@redhat.com
+ Cc: linux-kernel@vger.kernel.org
+ Cc: linux-perf-users@vger.kernel.org
---
✓ Signed: DKIM/amazon.com
---
Total patches: 5
---
Cover: ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.cover
Link: https://lore.kernel.org/r/20220504184850.24986-1-alisaidi@amazon.com
Base: not specified
git am ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.mbx
⬢[acme@toolbox perf]$
Somehow it is not being collected... :-\
Not even when I use:
> P.s. Ali missed to include German's review tag, see:
> https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com
Will try updating b4...
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
2022-05-11 18:28 ` Arnaldo Carvalho de Melo
@ 2022-05-11 18:29 ` Arnaldo Carvalho de Melo
-1 siblings, 0 replies; 28+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-05-11 18:29 UTC (permalink / raw)
To: Leo Yan
Cc: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Em Wed, May 11, 2022 at 03:28:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, May 11, 2022 at 10:20:04AM +0800, Leo Yan escreveu:
> > On Tue, May 10, 2022 at 01:28:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> > > > Add a flag to the perf mem data struct to signal that a request caused a
> > > > cache-to-cache transfer of a line from a peer of the requestor and
> > > > wasn't sourced from a lower cache level. The line being moved from one
> > > > peer cache to another has latency and performance implications. On Arm64
> > > > Neoverse systems the data source can indicate a cache-to-cache transfer
> > > > but not if the line is dirty or clean, so instead of overloading HITM
> > > > define a new flag that indicates this type of transfer.
> > > >
> > > > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > > > Reviewed-by: Leo Yan <leo.yan@linaro.org>
> > >
> > > Was this already merged on the ARM kernel tree?
> >
> > No, I don't think this patch has been merged on Arm kernel tree. I searched
> > Arm and Arm64 git repos, none of them has merged this patch.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?qt=author&q=Ali+Saidi
> > http://git.armlinux.org.uk/cgit/linux-arm.git/log/?qt=author&q=Ali+Saidi
> >
> > P.s. Ali missed to include German's review tag, see:
> > https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
> >
> > Do you want us to resend the patch set for adding tags?
>
> I use b4 and it should collect Reviewed-by, Acked-by, etc tags, for
> instance, if I use the message-id in your message:
>
> ⬢[acme@toolbox perf]$ b4 am -ctsl --cc-trailers 20220511022004.GA956170@leoy-ThinkPad-X240s
> Looking up https://lore.kernel.org/r/20220511022004.GA956170%40leoy-ThinkPad-X240s
> Grabbing thread from lore.kernel.org/all/20220511022004.GA956170%40leoy-ThinkPad-X240s/t.mbox.gz
> Checking for newer revisions on https://lore.kernel.org/all/
> Analyzing 12 messages in the thread
<SNIP>
> ✓ [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
> + Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> + Link: https://lore.kernel.org/r/20220504184850.24986-6-alisaidi@amazon.com
> + Cc: Nick.Forrington@arm.com
> + Cc: andrew.kilroy@arm.com
> + Cc: james.clark@arm.com
> + Cc: mark.rutland@arm.com
> + Cc: john.garry@huawei.com
> + Cc: lihuafei1@huawei.com
> + Cc: peterz@infradead.org
> + Cc: benh@kernel.crashing.org
> + Cc: acme@kernel.org
> + Cc: jolsa@kernel.org
> + Cc: namhyung@kernel.org
> + Cc: will@kernel.org
> + Cc: mathieu.poirier@linaro.org
> + Cc: kjain@linux.ibm.com
> + Cc: alexander.shishkin@linux.intel.com
> + Cc: linux-arm-kernel@lists.infradead.org
> + Cc: mingo@redhat.com
> + Cc: linux-kernel@vger.kernel.org
> + Cc: linux-perf-users@vger.kernel.org
> ---
> ✓ Signed: DKIM/amazon.com
> ---
> Total patches: 5
> ---
> Cover: ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.cover
> Link: https://lore.kernel.org/r/20220504184850.24986-1-alisaidi@amazon.com
> Base: not specified
> git am ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.mbx
> ⬢[acme@toolbox perf]$
>
> Somehow it is not being collected... :-\
>
> Not even when I use:
>
> > P.s. Ali missed to include German's review tag, see:
> > https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
>
>
> 458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com
>
> Will try updating b4...
Didn't help, so please collect the new tags and resubmit.
- Arnaldo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER
@ 2022-05-11 18:29 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 28+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-05-11 18:29 UTC (permalink / raw)
To: Leo Yan
Cc: Ali Saidi, linux-kernel, linux-perf-users, linux-arm-kernel,
german.gomez, benh, Nick.Forrington, alexander.shishkin,
andrew.kilroy, james.clark, john.garry, jolsa, kjain, lihuafei1,
mark.rutland, mathieu.poirier, mingo, namhyung, peterz, will
Em Wed, May 11, 2022 at 03:28:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, May 11, 2022 at 10:20:04AM +0800, Leo Yan escreveu:
> > On Tue, May 10, 2022 at 01:28:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, May 04, 2022 at 06:48:47PM +0000, Ali Saidi escreveu:
> > > > Add a flag to the perf mem data struct to signal that a request caused a
> > > > cache-to-cache transfer of a line from a peer of the requestor and
> > > > wasn't sourced from a lower cache level. The line being moved from one
> > > > peer cache to another has latency and performance implications. On Arm64
> > > > Neoverse systems the data source can indicate a cache-to-cache transfer
> > > > but not if the line is dirty or clean, so instead of overloading HITM
> > > > define a new flag that indicates this type of transfer.
> > > >
> > > > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > > > Reviewed-by: Leo Yan <leo.yan@linaro.org>
> > >
> > > Was this already merged on the ARM kernel tree?
> >
> > No, I don't think this patch has been merged on Arm kernel tree. I searched
> > Arm and Arm64 git repos, none of them has merged this patch.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?qt=author&q=Ali+Saidi
> > http://git.armlinux.org.uk/cgit/linux-arm.git/log/?qt=author&q=Ali+Saidi
> >
> > P.s. Ali missed to include German's review tag, see:
> > https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
> >
> > Do you want us to resend the patch set for adding tags?
>
> I use b4 and it should collect Reviewed-by, Acked-by, etc tags, for
> instance, if I use the message-id in your message:
>
> ⬢[acme@toolbox perf]$ b4 am -ctsl --cc-trailers 20220511022004.GA956170@leoy-ThinkPad-X240s
> Looking up https://lore.kernel.org/r/20220511022004.GA956170%40leoy-ThinkPad-X240s
> Grabbing thread from lore.kernel.org/all/20220511022004.GA956170%40leoy-ThinkPad-X240s/t.mbox.gz
> Checking for newer revisions on https://lore.kernel.org/all/
> Analyzing 12 messages in the thread
<SNIP>
> ✓ [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores
> + Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> + Link: https://lore.kernel.org/r/20220504184850.24986-6-alisaidi@amazon.com
> + Cc: Nick.Forrington@arm.com
> + Cc: andrew.kilroy@arm.com
> + Cc: james.clark@arm.com
> + Cc: mark.rutland@arm.com
> + Cc: john.garry@huawei.com
> + Cc: lihuafei1@huawei.com
> + Cc: peterz@infradead.org
> + Cc: benh@kernel.crashing.org
> + Cc: acme@kernel.org
> + Cc: jolsa@kernel.org
> + Cc: namhyung@kernel.org
> + Cc: will@kernel.org
> + Cc: mathieu.poirier@linaro.org
> + Cc: kjain@linux.ibm.com
> + Cc: alexander.shishkin@linux.intel.com
> + Cc: linux-arm-kernel@lists.infradead.org
> + Cc: mingo@redhat.com
> + Cc: linux-kernel@vger.kernel.org
> + Cc: linux-perf-users@vger.kernel.org
> ---
> ✓ Signed: DKIM/amazon.com
> ---
> Total patches: 5
> ---
> Cover: ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.cover
> Link: https://lore.kernel.org/r/20220504184850.24986-1-alisaidi@amazon.com
> Base: not specified
> git am ./v8_20220504_alisaidi_perf_arm_spe_decode_spe_source_and_use_for_perf_c2c.mbx
> ⬢[acme@toolbox perf]$
>
> Somehow it is not being collected... :-\
>
> Not even when I use:
>
> > P.s. Ali missed to include German's review tag, see:
> > https://lore.kernel.org/lkml/458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com/
>
>
> 458a2de1-dc93-7e2d-5dc5-fbcd670572b6@arm.com
>
> Will try updating b4...
Didn't help, so please collect the new tags and resubmit.
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2022-05-11 18:30 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-04 18:48 [PATCH v8 0/4] perf: arm-spe: Decode SPE source and use for perf c2c Ali Saidi
2022-05-04 18:48 ` Ali Saidi
2022-05-04 18:48 ` [PATCH v8 1/5] perf: Add SNOOP_PEER flag to perf mem data struct Ali Saidi
2022-05-04 18:48 ` Ali Saidi
2022-05-11 5:41 ` kajoljain
2022-05-11 5:41 ` kajoljain
2022-05-04 18:48 ` [PATCH v8 2/5] perf tools: sync addition of PERF_MEM_SNOOPX_PEER Ali Saidi
2022-05-04 18:48 ` Ali Saidi
2022-05-10 16:28 ` Arnaldo Carvalho de Melo
2022-05-10 16:28 ` Arnaldo Carvalho de Melo
2022-05-11 2:20 ` Leo Yan
2022-05-11 2:20 ` Leo Yan
2022-05-11 18:28 ` Arnaldo Carvalho de Melo
2022-05-11 18:28 ` Arnaldo Carvalho de Melo
2022-05-11 18:29 ` Arnaldo Carvalho de Melo
2022-05-11 18:29 ` Arnaldo Carvalho de Melo
2022-05-11 5:42 ` kajoljain
2022-05-11 5:42 ` kajoljain
2022-05-04 18:48 ` [PATCH v8 3/5] perf mem: Print snoop peer flag Ali Saidi
2022-05-04 18:48 ` Ali Saidi
2022-05-11 5:45 ` kajoljain
2022-05-11 5:45 ` kajoljain
2022-05-04 18:48 ` [PATCH v8 4/5] perf arm-spe: Don't set data source if it's not a memory operation Ali Saidi
2022-05-04 18:48 ` Ali Saidi
2022-05-04 18:48 ` [PATCH v8 5/5] perf arm-spe: Use SPE data source for neoverse cores Ali Saidi
2022-05-04 18:48 ` Ali Saidi
2022-05-05 15:03 ` Leo Yan
2022-05-05 15:03 ` Leo Yan
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.