Performance L2 TLB未命中后会发生什么？

我很难理解当翻译查找缓冲区的前两个级别导致未命中时会发生什么

我不确定“页面漫游”是否发生在特殊的硬件电路中，或者页面表是否存储在二级/三级缓存中，或者它们是否只驻留在主内存中。

（其中一些是针对x86和Intel的。大多数关键点适用于任何执行硬件页面漫游的CPU。我还讨论了像MIPS这样的ISA，它们通过软件处理TLB未命中。）

现代x86微体系结构具有专用的页面漫游硬件。它们甚至可以推测性地进行页面漫游，以便在TLB未命中实际发生之前加载TLB条目。。为了支持硬件虚拟化，页面漫游器可以在主机VM内处理来宾页面表。（来宾物理内存=主机虚拟内存，或多或少。VMWare已发布）

Skylake甚至可以同时执行两次页面漫游，请参阅。（Intel还将页面拆分负载惩罚从~100降低到~5或10个额外延迟周期，与缓存线拆分大致相同，但吞吐量更差。这可能与此有关，或者可能添加第二个页面漫游单元是发现页面拆分访问的单独响应。）（和TLB失误？）比他们之前在实际工作负载中估计的更重要）

当一个未缓存的PTE被推测性加载，但在第一次真正使用该条目之前，通过对页表的存储进行修改时，一些微体系结构将其视为错误推测。例如，对于任何早期指令未在体系结构上引用的仅推测性TLB条目，对页表条目的存储进行嗅探纳什

（Win9x依赖于此，CPU供应商关心的是不破坏重要的现有代码。在编写Win9x时，当前的TLB失效规则还不存在，因此它甚至不是一个bug；请参阅下面引用的Andy Glew评论）.AMD推土机系列违反了这一假设，只提供x86手册在纸上的说明

---

页面漫游硬件生成的页面表加载可以在L1、L2或L3缓存中命中。例如，可以在您选择的L1、L2、L3或内存（即缓存未命中）中计算页面漫游命中次数。事件名称为

PAGE_WALKER_LOADS。DTLB_L1

表示L1+FB中的DTLB PAGE WALKER命中数，其他表示ITLB和其他缓存级别

由于现代的页面目录项指向页面表项的表格，更高级别的PDE（页面目录项）值得在页面漫游硬件中进行缓存。这意味着。Intel和AMD实际上可以做到这一点。ARM和他们的

那篇论文说AMD CPU上的页面漫游加载忽略了L1，但确实通过了L2（可能是为了避免污染L1，或者减少读取端口的争用）。无论如何，这使得缓存一些高级PDE（每个PDE包含许多不同的翻译条目）成为可能在页面漫游硬件内部更具价值，因为指针追踪链的成本更高，延迟更高

但请注意，x86不保证TLB条目的负缓存。将页面从无效更改为有效并不需要（因此，如果真正的实现确实希望进行这种负缓存，它必须窥探或以某种方式仍然实现x86手册保证的语义。）

（历史注释：表示在P5和更早版本中，硬件页面漫游加载绕过了内部一级缓存（它通常是直写的，因此这使得页面漫游与存储一致）.IIRC，我的奔腾MMX主板在mobo上有二级缓存，可能是内存侧缓存。Andy还确认P6和更高版本确实从普通的L1d缓存加载

另一个答案在结尾也有一些有趣的链接，包括我在上一段末尾链接的文章。它似乎还认为操作系统可能会在页面错误时更新TLB本身，而不仅仅是页面表（HW pagewalk没有找到条目），并怀疑是否可以在x86上禁用HW pagewalk。（但实际上，操作系统只是修改内存中的页表，然后从

#PF

返回，重新运行出错指令，因此HW pagewalk这次将成功。）也许本文考虑的是类似于MIPS的ISA，其中软件TLB管理/未命中处理是可能的

我认为实际上不可能在P5（或任何其他x86）上禁用HW pagewalk。这需要软件使用专用指令（没有）或

wrmsr

或MMIO存储来更新TLB条目P5上的软件TLB处理速度更快。我想他的意思是，如果可能的话，速度会更快。当时他正在Imation（在MIPS上）工作，与x86 AFAIK不同，SW page walk是一个选项（有时是唯一的选项）

---

正如（关于TLB未命中的另一个问题），硬件页面漫游的最大优点是TLB未命中不一定会使CPU停止运行。（无序执行正常进行，直到重新排序缓冲区填满为止，因为加载/存储不能失效。失效按顺序发生，因为CPU不能正式提交前一条指令出现故障时不应发生的任何事情。）

顺便说一句，有可能构建一个x86 CPU，通过捕获到微码而不是专用的硬件状态机来处理TLB未命中。这将（大大？）降低性能，可能不值得进行推测性触发（因为从微码发出UOP意味着您不能从正在运行的代码发出指令。）

理论上，如果在单独的硬件线程（）SMT样式中运行这些UOP，微代码TLB处理可能并不可怕。 在从单线程切换到两个逻辑核的过程中，您需要它的启动/停止开销比正常的超线程少得多（必须等待