c - 在 x86 上的简单 PAPI 分析中意外出现大量 TLB 未命中

Question

我正在使用 PAPI 高级 API 检查循环遍历数组的简单程序中的 TLB 未命中，但看到的数字比预期的要大。

在其他简单的测试用例中，结果似乎相当合理，这让我认为结果是真实的，额外的未命中是由于硬件预取或类似原因造成的。

任何人都可以解释这些数字或指出我在使用 PAPI 时的一些错误吗？

int events[] = {PAPI_TLB_TL};
long long values[1];
char * databuf = (char *) malloc(4096 * 32);

if (PAPI_start_counters(events, 1) != PAPI_OK) exit(-1);
if (PAPI_read_counters(values, 1) != PAPI_OK) exit(-1); //Zeros the counters

for(int i=0; i < 32; ++i){
    databuf[4096 * i] = 'a';
}

if (PAPI_read_counters(values, 1) != PAPI_OK) exit(-1); //Extracts the counters

printf("%llu\n", values[0]);

我预计打印的数字在 32 左右，或者至少是一些倍数，但始终得到 93 或更高的结果(并非始终高于 96，即并非每次迭代仅错失 3 次)。我正在运行固定到一个核心上，上面没有其他任何东西(除了定时器中断)。

我在 Nehalem 上并且没有使用大页面，所以 DTLB 中有 64 个条目(L2 中有 512 个条目)。

Answer 1

基于评论:

• 如果使用 malloc()，将失误约 90 次。
• 如果使用 calloc() 或如果数组是事先迭代过的，则 32 次未命中。

原因是惰性分配。在您触摸内存之前，操作系统实际上不会为您提供内存。

当您第一次触摸页面时，会导致页面错误。操作系统将捕获此页面错误并即时正确分配它(which involves zeroing 等)。这是导致所有这些额外的 TLB 未命中的开销。

但是，如果您使用 calloc() 或提前接触所有内存，则可以将此开销移至启动计数器之前。因此结果较小。

至于剩下的32个失手……我就不知道了。
(或者如评论中所述，可能是 PAPI 干扰。)