商城网站建设模板下载,建设网站上传代码,网站更换服务器影响,上海网站建设怎么赚钱今天分享一篇TLB的好文章#xff0c;希望大家夯实基本功#xff0c;让我们一起深入理解计算机系统。 TLB 是 translation lookaside buffer 的简称。首先#xff0c;我们知道 MMU 的作用是把虚拟地址转换成物理地址。 MMU工作原理 虚拟地址和物理地址的映射关系存储在页表… 今天分享一篇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 需要转换成PAPA 里面才存储着数据。中间多经传一手所以引入了些问题。 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 全部 TLBASID 的管理可以使用 bitmap 管理flush TLB 后 clear 整个 bitmap。当我们建立页表映射的时候就需要 flush 虚拟地址对应的 TLB 表项。第一印象可能是修改页表映射的时候才需要 flush TLB但是实际情况是只要建立映射就需要 flush TLB。原因是建立映射时你并不知道之前是否存在映射例如建立虚拟地址 A 到物理地址 B 的映射我们并不知道之前是否存在虚拟地址 A 到物理地址 C 的映射情况所以就统一在建立映射关系的时候 flush TLB。 原文作者【 一起学嵌入式