TLB缓存是个神马鬼，如何查看TLB miss？

码农天地 - 2020-10-30 12:19:29

---

介绍TLB之前，我们先来回顾一个操作系统里的基本概念，虚拟内存。

虚拟内存

在用户的视角里，每个进程都有自己独立的地址空间，A进程的4GB和B进程4GB是完全独立不相关的，他们看到的都是操作系统虚拟出来的地址空间。但是呢，虚拟地址最终还是要落在实际内存的物理地址上进行操作的。操作系统就会通过页表的机制来实现进程的虚拟地址到物理地址的翻译工作。其中每一页的大小都是固定的。这一段我不想介绍的太过于详细，对这个概念不熟悉的同学回去翻一下操作系统的教材。

页表管理有两个关键点，分别是页面大小和页表级数

1.页面大小

在Linux下，我们通过如下命令可以查看到当前操作系统的页大小

# getconf PAGE_SIZE
4096  

可以看到当前我的Linux机器的页表是4KB的大小。

2.页表级数

页表级数越少，虚拟地址到物理地址的映射会很快，但是需要管理的页表项会很多，能支持的地址空间也有限。相反页表级数越多，需要的存储的页表数据就会越少，而且能支持到比较大的地址空间，但是虚拟地址到物理地址的映射就会越慢。32位系统的虚拟内存实现：二级页表

为了帮助大家回忆这段知识，我举个例子。如果想支持32位的操作系统下的4GB进程虚拟地址空间，假设页表大小为4K，则共有2的20次方页面。如果采用速度最快的1级页表，对应则需要2的20次方个页表项。一个页表项假如4字节，那么一个进程就需要（1048576*4=）4M的内存来存页表项。
如果是采用2级页表，如图1，则创建进程时只需要有一个页目录就可以了，占用(1024*4)=4KB的内存。剩下的二级页表项只有用到的时候才会再去申请。

64位系统的虚拟内存实现：四级页表

现在的操作系统需要支持的可是48位地址空间（理论上可以支持64位，但其实现在只支持到了48位，也足够用了），而且要支持成百上千的进程，如果不采用分级页表的方式，则创建进程时就需要为其维护一个2的36次方个页表项（64位Linux目前只使用了地址中的48位的，在这里面，最后12位都是页内地址，只有前36位才是用来寻找页表的）， 2^36 *4Byte=32GB，这个更不能忍了。 也必须和32位系统一样，进一步提高页表的级数。

Linux在v2.6.11以后，最终采用的方案是4级页表，分别是：

PGD：page Global directory(47-39), 页全局目录PUD：Page Upper Directory(38-30)，页上级目录PMD：page middle directory(29-21)，页中间目录PTE：page table entry(20-12)，页表项

这样，一个64位的虚拟空间，初始创建的时候只需要维护一个2^9 大小的一个页全局目录就够了，现在的页表数据结构被扩展到了8byte。这个页全局目录仅仅需要(2^9 *8=)4K，剩下的中间页目录、页表项只需要在使用的时候再分配就好了。Linux就是通过这种方式支持起(2^48 =)256T的进程地址空间的。

页表带来的问题

上面终于费劲扒了半天Linux虚拟内存的实现，我终于可以开始说我想说的重点了。
虽然创建一个支持256T的地址空间的进程在初始的时候只需要4K的页全局目录，但是，这也带来了额外的问题，页表是存在内存里的。那就是一次内存IO光是虚拟地址到物理地址的转换就要去内存查4次页表，再算上真正的内存访问，最坏情况下需要5次内存IO才能获取一个内存数据!!

TLB应运而生

和CPU的L1、L2、L3的缓存思想一致，既然进行地址转换需要的内存IO次数多，且耗时。那么干脆就在CPU里把页表尽可能地cache起来不就行了么，所以就有了TLB(Translation Lookaside Buffer)，专门用于改进虚拟地址到物理地址转换速度的缓存。其访问速度非常快，和寄存器相当，比L1访问还快。

我本来想实际看一下TLB的信息，但翻遍了Linux的各种命令，也没有找到像sysfs这么方便查看L1、L2、L3大小的方法。仅仅提供下图供大家参考吧！ （谁要是找到了查看TLB的命令，别忘了分享给飞哥啊，谢谢！）

有了TLB之后，CPU访问某个虚拟内存地址的过程如下

1.CPU产生一个虚拟地址2.MMU从TLB中获取页表，翻译成物理地址3.MMU把物理地址发送给L1/L2/L3/内存4.L1/L2/L3/内存将地址对应数据返回给CPU

由于第2步是类似于寄存器的访问速度，所以如果TLB能命中，则虚拟地址到物理地址的时间开销几乎可以忽略。如果想了解TLB更详细的工作机制，请参考《深入理解计算机系统-第9章虚拟内存》

工具

既然TLB缓存命中很重要，那么有什么工具能够查看你的系统里的命中率呢？ 还真有

# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses -p $PID
 Performance counter stats for process id '21047':  

           627,809 dTLB-loads  
             8,566 dTLB-load-misses          #    1.36% of all dTLB cache hits  
         2,001,294 iTLB-loads  
             3,826 iTLB-load-misses          #    0.19% of all iTLB cache hits  

扩展

因为TLB并不是很大，只有4k，而且现在逻辑核又造成会有两个进程来共享。所以可能会有cache miss的情况出现。而且一旦TLB miss造成的后果可比物理地址cache miss后果要严重一些，最多可能需要进行5次内存IO才行。建议你先用上面的perf工具查看一下你的程序的TLB的miss情况，如果确实不命中率很高，那么Linux允许你使用大内存页，很多大牛包括PHP7作者鸟哥也这样建议。这样将会大大减少页表项的数量，所以自然也会降低TLB cache miss率。所要承担的代价就是会造成一定程度的内存浪费。在Linux里，大内存页默认是不开启的。

开发内功修炼之CPU篇专辑：

1.你以为你的多核CPU都是真核吗？多核“假象”2.听说你只知内存，而不知缓存？CPU表示很伤心！3.TLB缓存是个神马鬼，如何查看TLB miss？4.进程/线程切换究竟需要多少开销？5.协程究竟比线程牛在什么地方？6.软中断会吃掉你多少CPU？7.一次系统调用开销到底有多大？8.一次简单的php请求redis会有哪些开销？9.函数调用太多了会有性能问题吗？

我的公众号是「开发内功修炼」，在这里我不是单纯介绍技术理论，也不只介绍实践经验。而是把理论与实践结合起来，用实践加深对理论的理解、用理论提高你的技术实践能力。欢迎你来关注我的公众号，也请分享给你的好友~~~

Tags 标签