我试图理解perf记录的缓存未命中 . 我有一个最小的程序：
int main(void)
{
return 0;
}
如果我编译这个：
gcc -std=c99 -W -Wall -Werror -O3 -S -o test.S test.c
我得到一个预期的小程序：
.file "test.c"
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
xorl %eax, %eax
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Debian 4.7.2-5) 4.7.2"
.section .note.GNU-stack,"",@progbits
只有两条指令 xorl 和 ret ，程序应该小于一个缓存行的大小，所以我希望如果我运行 perf -e "cache-misses:u" ./test 我应该只看到一个缓存未命中 . 但是，我反而看到2到400之间 . 类似地， perf -e "cache-misses" ./test 导致~700到~2500 .
这只是一个perf估计计数的情况，还是有一些关于缓存未命中的方式，使得它们的推理是近似的？例如，如果我在内存中生成然后读取整数数组，我可以推断预取（顺序访问应该允许完美的预取）还是还有其他的东西在起作用？
1 回答
进程内存空间不仅仅是关于你的代码，还有堆，堆栈等差异来源，数据段也会导致缓存未命中 .
process memory space http://www.tenouk.com/ModuleZ_files/cmemory003.png
我不认为你可以估计缓存未命中数，就像你无法预测多线程程序中每个线程的运行顺序一样 .
但是，缓存未命中分析对于查找和定位false sharing非常有用 . 以下是您可以参考的一些有用链接：
http://igoro.com/archive/gallery-of-processor-cache-effects/
http://qqibrow.github.io/CPU-Cache-Effects-and-Linux-Perf/