关于这个话题有一些问题，但没有一个真正的答案。问题是：如何测量 macOS 上的 L1、L2、L3（如果有）缓存未命中？
问题不在于 macOS 在理论上不提供这些值，即使没有任何外部工具也是如此。在 Instruments 中，我们可以使用 Counters 并转到 Recording Options...，如下所示：
但是，没有 L1 缓存未命中或 L2，而是 可以选择的可能项目的巨大列表：
那么，在测量 L1 和 L2 缓存未命中（如果有的话，甚至是 L3）时，我该如何计算它们呢？
为了检索那个神奇的“缓存未命中”数字，我应该注意列表中的哪个“缓存未命中”？
【问题讨论】：
标签： performance caching x86 performancecounter xcode-instruments
在 Ivy Bridge、Haswell、Broadwell 和 Goldmont 处理器上，您可以使用以下事件来计算来自未命中的可缓存1 加载指令的需求加载请求所需的数据缓存行数L1、L2 和 L3：分别为 MEM_LOAD_UOPS_RETIRED.L1_MISS、MEM_LOAD_UOPS_RETIRED.L2_MISS 和 MEM_LOAD_UOPS_RETIRED.L3_MISS。在 Skylake 及更高版本上，相应的事件称为：MEM_LOAD_RETIRED.L1_MISS、MEM_LOAD_RETIRED.L2_MISS 和 MEM_LOAD_RETIRED.L3_MISS。这些事件仅计算已停用的加载指令所需的缓存行。
在 Nehalem 及更高版本上，您可以使用以下事件来计算来自未命中 L1、L2 和 L3 的可缓存存储指令的需求存储请求所需的缓存行数：L2_RQSTS.ALL_RFO、L2_RQSTS.RFO_MISS、和OFFCORE_RESPONSE（MSR 位 1、17、26-29、30-37）。这些事件计算存储指令所需的缓存行，这些指令已从管道中退出或刷新。
仅计算停用的指令可能比根据场景计算所有指令的访问更有用。不幸的是，没有对应于MEM_LOAD_UOPS_* 的商店事件。但是，有一些加载事件会同时计算已退休和刷新的加载。其中包括用于 L1 加载未命中的 L2_RQSTS.ALL_DEMAND_DATA_RD、用于 L2 加载未命中的 L2_RQSTS.DEMAND_DATA_RD_MISS 和用于 L3 加载未命中的 OFFCORE_RESPONSE (MSR bits 0, 17, 26-29, 30-37)。请注意，前两个事件还包括来自 L1 硬件预取器的加载。 L2_RQSTS.DEMAND_DATA_RD_MISS 事件仅在 Ivy Bridge 及更高版本上受支持。在 Sandy Bridge 上，我认为可以通过 L2_RQSTS.ALL_DEMAND_DATA_RD 减去 L2_RQSTS.DEMAND_DATA_RD_HIT 来计算。
另请参阅：How does Linux perf calculate the cache-references and cache-misses events。
脚注：
(1) IN 指令在 Haswell 上被视为 MEM_LOAD_UOPS_RETIRED.L1_MISS 事件（请参阅：What does port-mapped I/O look like on Sandy Bridge）。我还根据经验验证了所有MEM_LOAD_UOPS_RETIRED.L1|2|3|LFB_MISS|HIT 事件不计算来自 UC 或 WC 内存类型的负载，并且它们确实计算来自 WP、WB 和 WT 内存类型的负载。请注意，手册仅提及 UC 负载被排除在外，并且仅针对某些事件。顺便说一句，MEM_UOPS_RETIRED.ALL_LOADS 计算所有内存类型的负载。
【讨论】：