小编Ori*_*kis的帖子

我正在perf_event_opensyscall之上进行自定义实现。

实施旨在支持各种的PERF_TYPE_HARDWARE，PERF_TYPE_SOFTWARE和PERF_TYPE_HW_CACHE事件上的任何核心特定的线程。

在英特尔® 64 位和 IA-32 架构软件开发人员手册第 3B 卷中，我看到以下用于测试 CPU (Kaby Lake) 的内容：

到目前为止，我的理解是，可以同时监视（理论上）无限的PERF_TYPE_SOFTWARE事件，但同时监视有限的（没有多路复用）PERF_TYPE_HARDWARE和PERF_TYPE_HW_CACHE事件，因为每个事件都是通过 CPU 的 PMU 计数器的有限（如上面的手册中所见）数量来衡量的。

因此，对于启用了超线程的四核 Kaby Lake CPU，我假设最多可以同时监视4 个PERF_TYPE_HARDWARE/PERF_TYPE_HW_CACHE事件（如果仅使用 4 个线程，则最多可监视 8 个）。

对上述假设进行试验后，我发现虽然我最多可以成功监控 4 个PERF_TYPE_HARDWARE事件（8 个线程），但对于PERF_TYPE_HW_CACHE最多只能同时监控 2 个事件的事件，情况并非如此！

我还尝试仅使用 4 个线程，但同时监控的“PERF_TYPE_HARDWARE”事件的上限仍然为 4。禁用超线程也会发生同样的情况！

有人可能会问：为什么需要避免多路复用。首先，实现需要尽可能准确，避免多路复用的潜在盲点，其次，当超过“上限”时，所有事件值都为 0...

PERF_TYPE_HW_CACHE我针对的事件是：

CACHE_LLC_READ(PERF_HW_CACHE_TYPE_ID.PERF_COUNT_HW_CACHE_LL.value  | PERF_HW_CACHE_OP_ID.PERF_COUNT_HW_CACHE_OP_READ.value << 8 | PERF_HW_CACHE_OP_RESULT_ID.PERF_COUNT_HW_CACHE_RESULT_ACCESS.value << 16),
CACHE_LLC_WRITE(PERF_HW_CACHE_TYPE_ID.PERF_COUNT_HW_CACHE_LL.value  | …

我正在尝试了解LLC-prefetch-missesSandy Bridge 性能事件的含义。

从linux内核源代码我看到了事件的定义：

[ C(OP_PREFETCH) ] = {\n    [ C(RESULT_ACCESS) ] = SNB_DMND_PREFETCH|SNB_L3_ACCESS,\n    [ C(RESULT_MISS)   ] = SNB_DMND_PREFETCH|SNB_L3_MISS,\n},\n

其中：\nSNB_DMND_PREFETCH = (SNB_PF_DATA_RD|SNB_PF_RFO)指向事件寄存器的位 4-5，而\nSNB_L3_MISS = (SNB_DRAM_ANY|SNB_NON_DRAM)指向事件寄存器的位 22-36。

阅读Intel\xc2\xae 64 and IA-32 Architectures Software Developer\xe2\x80\x99s Manual，第 3 卷，第 18.3.4.5 章，我发现：

SNB_DMND_PREFETCH代表事件寄存器的“Request_Type”字段和SNB_L3_MISS“Response_Type”字段MSR_OFFCORE_RSP_x

要求：

回复：

\n

但是，我无法理解预取上下文中“响应”的含义。

此外，我在一些课程幻灯片中发现了这个定义：

Prefetch Hit: Prefetched line that was hit in …