为什么修改指令会在 x86 上导致巨大的 i-cache 和 i-TLB 未命中？

Question

下面的代码片段创建了一个函数（有趣），只有一个 RET 指令。 循环反复调用函数，返回后覆盖RET指令的内容。

#include <sys/mman.h>
#include<stdlib.h>
#include<unistd.h>
#include <string.h>

typedef void (*foo)();
#define RET (0xC3)

int main(){
     // Allocate an executable page
    char * ins = (char *) mmap(0, 4096, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, 0, 0);
    // Just write a RET instruction
    *ins = RET;
    // make fun point to the function with just RET instruction
    foo fun = (foo)(ins);
    // Repeat 0xfffffff times
    for(long i = 0; i < 0xfffffff; i++){
        fun();
        *ins = RET;
    }
    return 0;
}

X86 Broadwell 机器上的 Linux 性能具有以下 icache 和 iTLB 统计信息：

性能统计 -e L1-icache-load-misses -e iTLB-load-misses ./a.out

“./a.out”的性能计数器统计信息：

   805,516,067      L1-icache-load-misses                                       
         4,857      iTLB-load-misses                                            

  32.052301220 seconds time elapsed

现在，在不覆盖 RET 指令的情况下查看相同的代码。

#include <sys/mman.h>
#include<stdlib.h>
#include<unistd.h>
#include <string.h>

typedef void (*foo)();
#define RET (0xC3)

int main(){
    // Allocate an executable page
    char * ins = (char *) mmap(0, 4096, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, 0, 0);
    // Just write a RET instruction
    *ins = RET;
    // make fun point to the function with just RET instruction
    foo fun = (foo)(ins);
    // Repeat 0xfffffff times
    for(long i = 0; i < 0xfffffff; i++){
        fun();
        // Commented *ins = RET;
    }
    return 0;
}

这是同一台机器上的性能统计数据。

性能统计 -e L1-icache-load-misses -e iTLB-load-misses ./a.out

“./a.out”的性能计数器统计信息：

        11,738      L1-icache-load-misses                                       
           425      iTLB-load-misses                                            

   0.773433500 seconds time elapsed

请注意，覆盖指令会导致 L1-icache-load-misses 从 11,738 增长到 805,516,067 - 多方面的增长。 另请注意，iTLB-load-misses 从 425 增长到 4,857 - 增长幅度很大，但与 L1-icache-load-misses 相比要少一些。 运行时间从 0.773433500 秒增长到 32.052301220 秒——增长了 41 倍！

如果指令占用空间如此之小，为什么 CPU 会导致 i-cache 未命中尚不清楚。这两个示例的唯一区别是修改了指令。既然 L1 iCache 和 dCache 是分开的，难道没有办法将代码安装到 iCache 中，从而避免缓存 i-cache 未命中吗？

此外，为什么 iTLB 未命中数增长了 10 倍？

Answer 1

虽然 L1 iCache 和 dCache 是分开的，但有没有办法将代码安装到 iCache 中以避免缓存 i-cache 未命中？

没有。

如果你想修改代码 - 唯一可以走的路径是：

1. 存储日期执行引擎
2. 存储缓冲和转发
3. L1 数据缓存
4. 统一二级缓存
5. L1 指令缓存

请注意，您也错过了 μOP 缓存。

this diagram¹ 对此进行了说明，我认为这已经足够准确了。

我怀疑 iTLB 未命中可能是由于定期 TLB 刷新造成的。在没有修改的情况下，您不会受到 iTLB 未命中的影响，因为您的指令实际上来自 μOP 缓存。

如果他们不这样做，我不太确定。我认为 L1 指令缓存是虚拟寻址的，因此如果命中则无需访问 TLB。

^{1：不幸的是，该图像的版权非常严格，因此我避免突出显示路径/内联图像。}