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 个PGD + 2^9 个PUD + 2^9 个PMD + 2^9 个PTE = 2048个页表数据结构。现在的页表数据结构被扩展到了8byte。仅仅需要(2048*8=)16K就可以支持起(2^48 =)256T的进程地址空间。

页表带来的问题

处理器引入MMU后，读取指令、数据需要访问两次内存：

首先通过查询页表得到物理地址，然后访问该物理地址读取指令、数据。

既由于页表存放在主存中，因此程序每次访存至少需要两次（单级页表）：一次访存获取物理地址，第二次访存才获得数据。

虽然16K的页表数据支持起了256T的地址空间寻址。但是，这也带来了额外的问题，页表是存在内存里的。那就是一次内存IO光是虚拟地址到物理地址的转换就要去内存查4次页表（4级），再算上真正的内存访问，竟然需要5次内存IO才能获取一个内存数据!!

TLB应运而生

为了减少因为MMU导致的处理器性能下降，引入了TLB，TLB是Translation Lookaside Buffer的简称，可翻译为“地址转换后援缓冲器”，也可简称为“快表”。

简单地说，TLB就是页表的Cache，其中存储了当前最可能被访问到的页表项，其内容是部分页表项的一个副本。只有在TLB无法完成地址翻译任务时，才会到内存中查询页表，这样就减少了页表查询导致的处理器性能下降。

TLB原理

当cpu要访问一个虚拟地址/线性地址时，CPU会首先根据虚拟地址的高20位（20是x86特定的，不同架构有不同的值）在TLB中查找。如果是表中没有相应的表项，称为TLB miss，需要通过访问慢速RAM中的页表计算出相应的物理地址。同时，物理地址被存放在一个TLB表项中，以后对同一线性地址的访问，直接从TLB表项中获取物理地址即可，称为TLB hit。

归纳如下：

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

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

想像一下x86_32架构下没有TLB的存在时的情况，对线性地址的访问，首先从PGD中获取PTE（第一次内存访问），在PTE中获取页框地址（第二次内存访问），最后访问物理地址，总共需要3次RAM的访问。如果有TLB存在，并且TLB hit，那么只需要一次RAM访问即可。

如何查看TLB miss

既然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

iTLB-loads可大于也可小于iTLB-load-misses：https:///questions/49933319/how-to-interpret-perf-itlb-loads-itlb-load-misses

On your Broadwell processor, perf maps iTLB-loads to ITLB_MISSES.STLB_HIT, which represents the event of a TLB lookup that misses the L1 ITLB but hits the unified TLB for all page sizes, and iTLB-load-misses to ITLB_MISSES.MISS_CAUSES_A_WALK, which represents the event of a TLB lookup that misses both the L1 ITLB and the unified TLB (causing a page walk) for all page sizes. Therefore, iTLB-load-misses can be larger or smaller than or equal to iTLB-loads. They are independent events.

扩展

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

perf 统计 内存相关event （https:///mrpre/article/details/83537311）

perf 可探测 的所有 event ，均可以使用命令perf list获得。

本文举几个和内存相关的性能的几个event例子

探测 进程 的缺页中断数(page fault)
perf stat -e faults ./mem
能够统计 ./mem 执行 周期内，引发的 缺页中断数。

Performance counter stats for './mem':

           100,126      faults                                                      

       0.203315268 seconds time elapsed

探测正在运行的进程，则使用
perf stat -e faults -p $PID运行，命令掐断后，打印出命令开始到命令结束时，目标进程的缺页中断数。

可以 使用 perf record来探测 指定 event 的热点函数，例如
perf record -e faults ./mem

使用
perf report
输出结果。

Samples: 655  of event 'faults', Event count (approx.): 100151                                                                               
Overhead  Command  Shared Object     Symbol                                                                                                  
  99.57%  mem      mem               [.] func
   0.35%  mem      ld-2.17.so        [.] _dl_lookup_symbol_x
   0.06%  mem      ld-2.17.so        [.] _dl_important_hwcaps
   0.01%  mem      ld-2.17.so        [.] _dl_start
   0.00%  mem      ld-2.17.so        [.] _start
   0.00%  mem      [kernel.vmlinux]  [k] __clear_user
   0.00%  mem      [kernel.vmlinux]  [k] copy_user_enhanced_fast_string

原理
在内核缺页中断处，有perf的钩子，用于统计缺页中断的次数：

perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);

内核源码中搜索 PERF_COUNT_SW_PAGE_FAULTS即可。

探测 进程 TLB相关event
perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses,L1-icache-load-misses ./mem
或者指定进程id进行探测
perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses,L1-icache-load-misses -p $PID

$perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses,L1-icache-load-misses ./mem

 Performance counter stats for './mem':

        89,946,326      dTLB-loads                                                    (80.09%)
            17,030      dTLB-load-misses          #    0.02% of all dTLB cache hits   (40.47%)
                10      iTLB-loads                                                    (39.96%)
               137      iTLB-load-misses          #  1370.00% of all iTLB cache hits   (59.80%)
            98,113      L1-icache-load-misses                                         (79.65%)

       0.201743107 seconds time elapsed

因为是 硬件event，所以不同的CPU架构，这些值代表的不一样。一样的是，dTLB代表了数据的TLB统计，iTLB代表的是指令的TLB统计。