caching - VIPT 缓存 : Connection between TLB & Cache?

Question

我只是想澄清这个概念，并且可以找到足够详细的答案，这些答案可以对硬件中的一切实际运作方式有所了解。请提供任何相关细节。

在 VIPT 缓存的情况下，内存请求并行发送到 TLB 和缓存。

从 TLB 中，我们得到了经过翻译的物理地址。
从缓存索引我们得到一个标签列表(例如，来自属于一个集合的所有缓存行)。

然后将转换后的 TLB 地址与标签列表进行匹配以找到候选者。

我的问题是在哪里执行此检查？

在缓存中？

如果不在缓存中，还有哪里？

如果在Cache中进行检查，则

是否存在从 TLB 到缓存模块的边带连接以获取
与标签地址比较需要转换的物理地址？

有人可以对“实际上”这是如何实现的以及缓存模块与 TLB(MMU) 模块之间的连接有所了解吗？

我知道这取决于特定的架构和实现。
但是，当有 VIPT 缓存时，您知道的实现是什么？

谢谢。

Answer 1

在这个详细级别，您必须将“缓存”和“TLB”分解为它们的组成部分 。它们在设计中非常紧密地相互连接，该设计使用了与标签提取并行翻译的 VIPT 速度技巧(即利用索引位都低于页面偏移量，因此被“免费”翻译。相关:Why is the size of L1 cache smaller than that of the L2 cache in most of the processors?)
L1dTLB 本身是一个小/快速 Content addressable memory，具有(例如)64 个条目和 4 路组关联( Intel Skylake )。大页通常使用并行检查的第二个(和第三个)数组来处理，例如32-entry 4-way for 2M pages, and for 1G pages: 4-entry full (4-way) associative。
但是现在，请简化您的心智模型并忘记大页面。
L1dTLB 是单个 CAM，检查它是单个查找操作。
“缓存” 至少包含以下部分:

存储标签+数据的SRAM阵列

控制逻辑根据索引位获取一组数据+标签。 (高性能 L1d 缓存通常与标签并行获取集合中所有方式的数据，以减少命中延迟而不是等待直到选择正确的标签，就像使用更大、更高关联性的缓存一样。)

比较器根据转换后的地址检查标签，如果其中之一匹配，则选择正确的数据，或触发错误处理。 (并且在命中时，更新 LRU 位以将此方式标记为最近使用)。有关没有 TLB 的 2 路关联缓存的基础图，请参阅 https://courses.cs.washington.edu/courses/cse378/09wi/lectures/lec16.pdf#page=17 。圆圈内的 = 是比较器:如果标签宽度输入相等，则产生 bool 真输出。

L1dTLB 并没有真正与 L1D 缓存分开。我实际上并不设计硬件，但我认为 现代高性能设计中的负载执行单元的工作原理类似于 :

AGU 从寄存器 + 偏移量生成地址。

(有趣的事实:Sandybridge 家族乐观地将这个过程简化为简单寻址模式:如果 reg 值与 [reg + 0-2047] 位于相同的 4k 页中，则 reg+disp 的负载使用延迟比其他寻址模式低 1c。 Is there a penalty when base+offset is in a different page than the base?)

索引位来自地址的页内偏移量部分，因此它们不需要从虚拟转换为物理。或者翻译是一个空操作。这种具有 PIPT 缓存非混叠的 VIPT 速度只要 L1_size / associativity <= page_size 就可以工作。例如32kiB/8 路 = 4k 页。
索引位选择一组。标签+数据是针对该集合的所有方式并行获取的。 (这会消耗功率以节省延迟，并且可能仅对 L1 来说是值得的。更高的关联性(每组更多的方式)L3 缓存绝对不是)

在 L1dTLB CAM 阵列中查找地址的高位。

标签比较器接收转换后的物理地址标签和从该集合中提取的标签。

如果存在标记匹配，缓存会从匹配的数据中提取正确的字节(使用地址的行内偏移低位和操作数大小)。

或者，不是获取完整的 64 字节行，而是可以使用更早的偏移位从每条路径获取一个(对齐的)字。没有高效未对齐负载的 CPU 肯定是这样设计的。我不知道这样做是否值得为支持未对齐负载的 CPU 上的简单对齐负载省电。
但是现代 Intel CPU(P6 及更高版本)对未对齐的加载 uops 没有任何惩罚，即使对于 32 字节向量，只要它们不跨越缓存线边界。并行 8 路的字节粒度索引可能比仅获取整个 8 x 64 字节并在 fetch+TLB 发生时设置输出的多路复用花费更多，基于偏移量、操作数大小和特殊属性，如零或符号扩展，或广播负载。因此，一旦标记比较完成，来自所选方式的 64 字节数据可能会进入已配置的多路复用网络，该网络获取正确的字节并进行广播或符号扩展。
AVX512 CPU 甚至可以执行 64 字节全线加载。

如果 L1dTLB CAM 中没有匹配项，则整个缓存获取操作将无法继续。我不确定 CPU 是否/如何管理此管道，以便在解决 TLB 未命中时其他负载可以继续执行。该过程涉及检查 L2TLB(Skylake:统一 1536 条目 12 路用于 4k 和 2M，16 条目用于 1G)，如果失败，则进行页面遍历。
我假设 TLB 未命中会导致标签+数据提取被丢弃。一旦找到所需的翻译，它们将被重新获取。当其他负载正在运行时，它们无处可放。
最简单的是，当翻译准备好时，它可以重新运行整个操作(包括从 L1dTLB 获取翻译)，但它可以通过缩短过程并直接使用翻译而不是放置来降低 L2TLB 命中的延迟它进入 L1dTLB 并再次取出。
显然，这需要将 dTLB 和 L1D 真正设计在一起并紧密集成。因为他们只需要互相交谈，这是有道理的。硬件页面遍历通过 L1D 缓存获取数据。 (页表总是有已知的物理地址，以避免捕获 22/鸡蛋问题)。

is there a side-band connection from TLB to the Cache?

我不会称之为边带连接。 L1D 缓存是唯一使用 L1dTLB 的东西。同样，L1iTLB 仅由 L1I 缓存使用。
如果有第二级 TLB，通常是统一的，所以 L1iTLB 和 L1dTLB 都会检查是否未命中。就像拆分的 L1I 和 L1D 缓存通常在未命中时检查统一的 L2 缓存一样。
外部缓存(L2、L3)是非常普遍的 PIPT。转换发生在 L1 检查期间，因此可以将物理地址发送到其他缓存。