标签：linux虚拟存储器 linux内核 虚拟地址 物理地址 tlb
TLB - translation lookaside buffer
快表，直译为翻译后备缓冲器，也可以理解为页表缓冲，地址变换高速缓存。
由于页表存放在主存中，因此程序每次访存至少需要两次：一次访存获取物理地址，第二次访存才获得数据。提高访存性能的关键在于依靠页表的访问局部性。当一个转换的虚拟页号被使用时，它可能在不久的将来再次被使用到，。
TLB是一种高速缓存，内存管理硬件使用它来改善虚拟地址到物理地址的转换速度。当前所有的个人桌面，笔记本和服务器处理器都使用TLB来进行虚拟地址到物理地址的映射。使用TLB内核可以快速的找到虚拟地址指向物理地址，而不需要请求RAM内存获取虚拟地址到物理地址的映射关系。这与data cache和instruction caches有很大的相似之处。
TLB原理
当cpu要访问一个虚拟地址/线性地址时，CPU会首先根据虚拟地址的高20位（20是x86特定的，不同架构有不同的值）在TLB中查找。如果是表中没有相应的表项，称为TLB miss，需要通过访问慢速RAM中的页表计算出相应的物理地址。同时，物理地址被存放在一个TLB表项中，以后对同一线性地址的访问，直接从TLB表项中获取物理地址即可，称为TLB hit。
想像一下x86_32架构下没有TLB的存在时的情况，对线性地址的访问，首先从PGD中获取PTE（第一次内存访问），在PTE中获取页框地址（第二次内存访问），最后访问物理地址，总共需要3次RAM的访问。如果有TLB存在，并且TLB hit，那么只需要一次RAM访问即可。
TLB表项
TLB内部存放的基本单位是页表条目，对应着RAM中存放的页表条目。页表条目的大小固定不变的，所以TLB容量越大，所能存放的页表条目越多，TLB hit的几率也越大。但是TLB容量毕竟是有限的，因此RAM页表和TLB页表条目无法做到一一对应。因此CPU收到一个线性地址，那么必须快速做两个判断：
1 所需的也表示否已经缓存在TLB内部（TLB miss或者TLB hit）
2 所需的页表在TLB的哪个条目内
为了尽量减少CPU做出这些判断所需的时间，那么就必须在TLB页表条目和内存页表条目之间的对应方式做足功夫
全相连 - full associative
在这种组织方式下，TLB cache中的表项和线性地址之间没有任何关系，也就是说，一个TLB表项可以和任意线性地址的页表项关联。这种关联方式使得TLB表项空间的利用率最大。但是延迟也可能相当的大，因为每次CPU请求，TLB硬件都把线性地址和TLB的表项逐一比较，直到TLB hit或者所有TLB表项比较完成。特别是随着CPU缓存越来越大，需要比较大量的TLB表项，所以这种组织方式只适合小容量TLB
直接匹配
每一个线性地址块都可通过模运算对应到唯一的TLB表项，这样只需进行一次比较，降低了TLB内比较的延迟。但是这个方式产生冲突的几率非常高，导致TLB miss的发生，降低了命中率。
比如，我们假定TLB cache共包含16个表项，CPU顺序访问以下线性地址块：1, 17 , 1, 33。当CPU访问地址块1时，1 mod 16 = 1，TLB查看它的第一个页表项是否包含指定的线性地址块1，包含则命中，否则从RAM装入；然后CPU方位地址块17，17 mod 16 = 1，TLB发现它的第一个页表项对应的不是线性地址块17，TLB miss发生，TLB访问RAM把地址块17的页表项装入TLB；CPU接下来访问地址块1，此时又发生了miss，TLB只好访问RAM重新装入地址块1对应的页表项。因此在某些特定访问模式下，直接匹配的性能差到了极点
组相连 - set-associative
为了解决全相连内部比较效率低和直接匹配的冲突，引入了组相连。这种方式把所有的TLB表项分成多个组，每个线性地址块对应的不再是一个TLB表项，而是一个TLB表项组。CPU做地址转换时，首先计算线性地址块对应哪个TLB表项组，然后在这个TLB表项组顺序比对。按照组长度，我们可以称之为2路，4路，8路。
经过长期的工程实践，发现8路组相连是一个性能分界点。8路组相连的命中率几乎和全相连命中率几乎一样，超过8路，组内对比延迟带来的缺点就超过命中率提高带来的好处了。
这三种方式各有优缺点，组相连是个折衷的选择，适合大部分应用环境。当然针对不同的领域，也可以采用其他的cache组织形式。
TLB表项更新
TLB表项更新可以有TLB硬件自动发起，也可以有软件主动更新
1. TLB miss发生后，CPU从RAM获取页表项，会自动更新TLB表项
2. TLB中的表项在某些情况下是无效的，比如进程切换，更改内核页表等，此时CPU硬件不知道哪些TLB表项是无效的，只能由软件在这些场景下，刷新TLB。
在linux kernel软件层，提供了丰富的TLB表项刷新方法，但是不同的体系结构提供的硬件接口不同。比如x86_32仅提供了两种硬件接口来刷新TLB表项：
1. 向cr3寄存器写入值时，会导致处理器自动刷新非全局页的TLB表项
2. 在Pentium Pro以后，invlpg汇编指令用来无效指定线性地址的单个TLB表项无效。
TLB刷新机制
在MMU开启的情形下，线性地 址到物理地址的转换需要经过页表的查找，如果每次都这么做的话显然对系统性能有影响，因此出现了这么一个cache，用来将已经此前的查找结果保存在这个 TLB中。显然TLB因为容量的限制不可能将所有的线性地址到物理地址的转换全部容纳进去，当TLB中所有的entry都被放置满的时候，处理器会决定将
一个旧的entry替换掉。
TLB本质上就是一块cache，所以也存在cache一致性的问题，比如如果操作系统修改了页表中的某一项 的映射关系，如果该项的映射恰好保存在TLB中，那么就出现了一致性的问题。与x86下系统物理内存与处理器间的cache一致性不一样，TLB的一致性 需要系统软件出面解决，而不是硬件。x86为此提供了两种方式来解决TLB一致性的问题：
1. 更新CR3. 如果cr3寄存器被重新加载，那么会导致整个TLB无效，OS可以通过比如： mov eax, cr3; move cr3, eax;这样的指令来刷新整个TLB。还有，我们知道Linux下进程切换时，会重新加载cr3寄存器，因为新老进程的页表项是不相同的，因此需要使 TLB无效防止出现不一致的情况。
2. x86提供了一条INVLPG指令，该指令是特权指令。操作系统可以通过该指令对TLB中的单独的某一entry进行更新。关于这条指令的详细信息，可以 参考一下 intel 64 and IA32 Architecture Software Developer‘s Manual. Linux kernel中使用到该指令的例子有：
<arch/x86/mm/pgtable.c>
void set_pte_vaddr(unsigned long vaddr, pte_t pteval)
{
...
/*
* It‘s enough to flush this one mapping.
* (PGE mappings get flushed as well)
*/
__flush_tlb_one(vaddr);
}
set_pte_vaddr函数在内核中被用来直接操作页目录表项，里面涉及到x86线性地址映射物理地址的原理，函数在最后调用__flush_tlb_one来刷新TLB中对应的项：
<arch/x86/mm/pgtable_32.c>
static inline void __flush_tlb_one(unsigned long addr)
{
if (cpu_has_invlpg)
__flush_tlb_single(addr);
else
__flush_tlb();
}
从函数的实现可以看到，如果CPU支持INVLPG指令，那么就调用 __flush_tlb_single函数来刷新TLB中的项(具体哪一项由虚拟线性地址addr来指定)，__flush_tlb_single的实现是：
static inline void __native_flush_tlb_single(unsigned long addr)
{
asm volatile("invlpg (%0)" ::"r" (addr) : "memory");
}
上面是一个非常直观的invlpg指令使用范例。在__flush_tlb_one函数中，我们还可以看到__flush_tlb的调用，后者被用来刷新整个TLB，其实就是本文前面提到的用mov指令倒换一下重写cr3.
在分页机制打开的情形下，当CPU要访问一个线性地址时，首先会查找TLB，如果该线性地址的转换已经存放在TLB中了，那么直接取得物理地址了(实际上TLB中存放的是VPN和PPN的映射)，此时不需要去查页目录页表了。
如果当前线性地址的映射尚没有保存在TLB中，那么就发生了一次TLB miss，此时需要查找页目录和页表项，然后把映射结果记录到TLB中。
标签：linux虚拟存储器 linux内核 虚拟地址 物理地址 tlb
原文地址：http://blog.csdn.net/hustyangju/article/details/40587841
