今天分享一篇TLB的好文章，希望大家夯实基本功，让我们一起深入理解计算机系统。

TLB 是 translation lookaside buffer 的简称。首先，我们知道 MMU 的作用是把虚拟地址转换成物理地址。

MMU工作原理

虚拟地址和物理地址的映射关系存储在页表中，而现在页表又是分级的。64 位系统一般都是 3~5 级。常见的配置是 4 级页表，就以 4 级页表为例说明。分别是 PGD、PUD、PMD、PTE 四级页表。在硬件上会有一个叫做页表基地址寄存器，它存储 PGD 页表的首地址。

Linux分页机制

MMU 就是根据页表基地址寄存器从 PGD 页表一路查到 PTE，最终找到物理地址（PTE页表中存储物理地址）。这就像在地图上显示你的家在哪一样，我为了找到你家的地址，先确定你是中国，再确定你是某个省，继续往下某个市，最后找到你家是一样的原理。一级一级找下去。这个过程你也看到了，非常繁琐。如果第一次查到你家的具体位置，我如果记下来你的姓名和你家的地址。下次查找时，是不是只需要跟我说你的姓名是什么，我就直接能够告诉你地址，而不需要一级一级查找。

四级页表查找过程需要四次内存访问。延时可想而知，非常影响性能。页表查找过程的示例如下图所示。以后有机会详细展开，这里了解下即可。

page table walk

TLB 的本质是什么

TLB 其实就是一块高速缓存。

数据 cache 缓存地址（虚拟地址或者物理地址）和数据。TLB 缓存虚拟地址和其映射的物理地址。TLB 根据虚拟地址查找 cache，它没得选，只能根据虚拟地址查找。

所以 TLB 是一个虚拟高速缓存。硬件存在 TLB 后，虚拟地址到物理地址的转换过程发生了变化。虚拟地址首先发往 TLB 确认是否命中 cache，如果 cache hit 直接可以得到物理地址。

否则，一级一级查找页表获取物理地址。并将虚拟地址和物理地址的映射关系缓存到 TLB 中。既然 TLB 是虚拟高速缓存（VIVT），是否存在别名和歧义问题呢？如果存在，软件和硬件是如何配合解决这些问题呢？

TLB 的特殊

虚拟地址映射物理地址的最小单位是 4KB。所以 TLB 其实不需要存储虚拟地址和物理地址的低 12 位(因为低 12 位是一样的，根本没必要存储)。

另外，我们如果命中 cache，肯定是一次性从 cache 中拿出整个数据。所以虚拟地址不需要 offset 域。index 域是否需要呢？这取决于cache的组织形式。

如果是全相连高速缓存。那么就不需要 index。如果使用多路组相连高速缓存，依然需要index。

下图就是一个四路组相连 TLB 的例子。现如今 64 位 CPU 寻址范围并没有扩大到 64 位。64 位地址空间很大，现如今还用不到那么大。

因此硬件为了设计简单或者解决成本，实际虚拟地址位数只使用了一部分。这里以 48 位地址总线为例说明。

TLB 的别名问题

我先来思考第一个问题，别名是否存在。我们知道 PIPT 的数据 cache 不存在别名问题。物理地址是唯一的，一个物理地址一定对应一个数据。但是不同的物理地址可能存储相同的数据。

也就是说，物理地址对应数据是一对一关系，反过来是多对一关系。由于 TLB 的特殊性，存储的是虚拟地址和物理地址的对应关系。

因此，对于单个进程来说，同一时间一个虚拟地址对应一个物理地址，一个物理地址可以被多个虚拟地址映射。

将 PIPT 数据 cache 类比 TLB，我们可以知道TLB 不存在别名问题。而 VIVT Cache 存在别名问题，原因是 VA 需要转换成PA，PA 里面才存储着数据。中间多经传一手，所以引入了些问题。

TLB的歧义问题

我们知道不同的进程之间看到的虚拟地址范围是一样的，所以多个进程下，不同进程的相同的虚拟地址可以映射不同的物理地址。这就会造成歧义问题。

例如，进程A将地址 0x2000 映射物理地址 0x4000。进程 B 将地址 0x2000 映射物理地址 0x5000。当进程 A 执行的时候将 0x2000 对应0x4000 的映射关系缓存到 TLB 中。当切换 B 进程的时候，B 进程访问 0x2000 的数据，会由于命中 TLB 从物理地址0x4000取数据。

这就造成了歧义。如何消除这种歧义，我们可以借鉴 VIVT 数据 cache 的处理方式，在进程切换时将整个 TLB 无效。切换后的进程都不会命中 TLB，但是会导致性能损失。

  资料直通车：Linux内核源码技术学习路线+视频教程内核源码

学习直通车：Linux内核源码内存调优文件系统进程管理设备驱动/网络协议栈

如何尽可能地避免 flush TLB

首先需要说明的是，这里的 flush 理解成使无效的意思。我们知道进程切换的时候，为了避免歧义，我们需要主动 flush 整个 TLB。如果我们能够区分不同的进程的 TLB 表项就可以避免 flush TLB。

我们知道 Linux 如何区分不同的进程，每个进程拥有一个独一无二的进程 ID。如果 TLB 在判断是否命中的时候，除了比较 tag 以外，再额外比较进程 ID 该多好呢！这样就可以区分不同进程的TLB表项。

进程 A 和 B 虽然虚拟地址一样，但是进程 ID 不一样，自然就不会发生进程 B 命中进程 A 的 TLB 表项。所以，TLB 添加一项 ASID(Address Space ID) 的匹配。

ASID 就类似进程 ID 一样，用来区分不同进程的 TLB 表项。这样在进程切换的时候就不需要 flush TLB。但是仍然需要软件管理和分配 ASID。

如何管理 ASID

ASID 和进程 ID 肯定是不一样的，别混淆二者。进程 ID 取值范围很大。但是ASID 一般是 8 或 16 bit。所以只能区分 256 或 65536 个进程。我们的例子就以 8 位ASID说明。

所以我们不可能将进程 ID 和 ASID 一一对应，我们必须为每个进程分配一个ASID，进程 ID 和每个进程的 ASID 一般是不相等的。

每创建一个新进程，就为之分配一个新的 ASID。当 ASID 分配完后，flush 所有 TLB，重新分配 ASID。

所以，如果想完全避免 flush TLB的话，理想情况下，运行的进程数目必须小于等于 256。然而事实并非如此，因此管理 ASID 上需要软硬结合。

Linux kernel 为了管理每个进程会有个 task_struct 结构体，我们可以把分配给当前进程的 ASID 存储在这里。页表基地址寄存器有空闲位也可以用来存储ASID。当进程切换时，可以将页表基地址和 ASID （可以从 task_struc t获得）共同存储在页表基地址寄存器中。

当查找 TLB 时，硬件可以对比 tag 以及 ASID 是否相等（对比页表基地址寄存器存储的 ASID 和 TLB 表项存储的 ASID）。如果都相等，代表 TLB hit。否则TLB miss。当 TLB miss 时，需要多级遍历页表，查找物理地址。然后缓存到TLB 中，同时缓存当前的 ASID。

多个进程共享

我们知道内核空间和用户空间是分开的，并且内核空间是所有进程共享。既然内核空间是共享的，进程 A 切换进程 B 的时候，如果进程 B 访问的地址位于内核空间，完全可以使用进程 A 缓存的 TLB。但是现在由于 ASID 不一样，导致 TLB miss。

我们针对内核空间这种全局共享的映射关系称之为 global 映射。针对每个进程的映射称之为 non-global 映射。

所以，我们在最后一级页表中引入一个 bit （non-global (nG) bit）代表是不是 global 映射。当虚拟地址映射物理地址关系缓存到 TLB 时，将 nG bit 也存储下来。

当判断是否命中 TLB 时，当比较 tag 相等时，再判断是不是 global 映射，如果是的话，直接判断 TLB hit，无需比较 ASID。当不是 global 映射时，最后比较 ASID 判断是否 TLB hit。

什么时候应该flush TLB

我们再来最后的总结，什么时候应该 flush TLB。

• 当 ASID 分配完的时候，需要 flush 全部 TLB，ASID 的管理可以使用 bitmap 管理，flush TLB 后 clear 整个 bitmap。
• 当我们建立页表映射的时候，就需要 flush 虚拟地址对应的 TLB 表项。第一印象可能是修改页表映射的时候才需要 flush TLB，但是实际情况是只要建立映射就需要 flush TLB。原因是，建立映射时你并不知道之前是否存在映射，例如，建立虚拟地址 A 到物理地址 B 的映射，我们并不知道之前是否存在虚拟地址 A 到物理地址 C 的映射情况，所以就统一在建立映射关系的时候 flush TLB。

原文作者：【 一起学嵌入式