Re: [PATCH 1/3] perf: Add macros to specify onchip L2/L3 accesses
From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2021-09-08 07:18:32
Also in:
linux-perf-users, lkml
Kajol Jain [off-list ref] writes:
Add couple of new macros to represent onchip L2 and onchip L3 accesses.
It would be "on chip". But I think this needs much more explanation, this is a generic header so these definitions need to make sense, and have an understood meaning, across all architectures. I think most people are going to read "on chip" as differentiating between an L2/L3 that is "on chip" vs "off chip". But the case you're trying to express is "another core's L2/L3 on the same chip as the CPU", vs "the current CPU's L2/L3".
quoted hunk ↗ jump to hunk
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h index f92880a15645..030b3e990ac3 100644 --- a/include/uapi/linux/perf_event.h +++ b/include/uapi/linux/perf_event.h@@ -1265,7 +1265,9 @@ union perf_mem_data_src { #define PERF_MEM_LVLNUM_L2 0x02 /* L2 */ #define PERF_MEM_LVLNUM_L3 0x03 /* L3 */ #define PERF_MEM_LVLNUM_L4 0x04 /* L4 */ -/* 5-0xa available */ +#define PERF_MEM_LVLNUM_OC_L2 0x05 /* On Chip L2 */ +#define PERF_MEM_LVLNUM_OC_L3 0x06 /* On Chip L3 */
The obvious use for 5 is for "L5" and so on. I'm not sure adding new levels is the best idea, because these don't fit neatly into the hierarchy, they are off to the side. I wonder if we should use the remote field. ie. for another core's L2 we set: mem_lvl = PERF_MEM_LVL_L2 mem_remote = 1 Which would mean "remote L2", but not remote enough to be lvl = PERF_MEM_LVL_REM_CCE1. It would be printed by the existing tools/perf code as "Remote L2", vs "Remote cache (1 hop)", which seems OK. ie. we'd be able to express: Current core's L2: LVL_L2 Other core's L2: LVL_L2 | REMOTE Other chip's L2: LVL_REM_CCE1 | REMOTE And similarly for L3. I think that makes sense? Unless people think remote should be reserved to mean on another chip, though we already have REM_CCE1 for that. cheers