Cache Locality - TLB、Cache Lines 和 ...?

如何解决Cache Locality - TLB、Cache Lines 和 ...?

根据我的理解，产生“缓存局部性”高级概念的结构如下：

1. 用于虚拟内存翻译的翻译后备缓冲区 (TLB)。在 4096 字节对齐（页面大小）内访问相同的虚拟内存将防止操作系统需要下降分层页表进行转换。

2. 缓存行意味着在 64 字节对齐（缓存行大小）内访问相同的虚拟内存将防止操作系统需要从 RAM 中获取指令。

我有几个问题：

1. 我从未见过对典型页表下降的定量估计。以时钟周期衡量，这真的很重要吗？

2. 我相信 64 字节缓存线是指 L1 缓存线 - L2 / L3 有不同的大小吗？什么情况下内存加载到L2/L3？

3. 除了缓存行和 TLB 之外，是否还有其他结构可以产生“缓存局部性”？

解决方法

与“缓存局部性”的一般主题相关的缓存存储器层次结构有很多其他与性能相关的功能。在 2007 年的一次演讲中，我提出了 25 种不同的局部性，可能需要考虑这些局部性才能理解受内存访问限制的应用程序的性能！ http://dx.doi.org/10.13140/RG.2.2.12967.27048 的演示文稿有两个版本——有和没有演讲者备注。幻灯片 7 提供了“内存层次结构局部域”的（不完整）列表。这包括与地址转换机制相关的局部性、与缓存访问相关的局部性、与 DRAM 访问相关的局部性以及一些其他主题。

,

1. 在大多数 ISA（包括我怀疑您正在考虑的 x86）上，硬件在 TLB 未命中时遍历页表，而不是操作系统。操作系统只是将数据结构放在内存中，并为 CPU 提供顶级页目录的物理地址。 What happens after a L2 TLB miss?。因此，可以在实际需要 TLB 条目之前推测性地完成页面遍历，理想情况下可以隐藏大部分延迟。

遇到 TLB 未命中（但数据的 L1d 命中）的负载的实际延迟会告诉您有关页面遍历延迟的信息，无论您正在测量什么微架构。我没有想到 Skylake 或任何东西的数字；实际成本还取决于页表硬件内部对更高级别的页表进行了多少缓存。 （所以这是另一个局部性来源；在与另一个最近的页面遍历相同的 1GiB 中的页面遍历可能会更快，即使不只使用 1G 或 2M 的巨大/大页面，这样一个 TLB 条目可以覆盖更多的地址空间。）>

2. 一些微架构对 L2 或 L3 使用更大的线，但大多数没有。所有现代 x86 CPU 都使用 64B 线。 （但英特尔的 L2 空间预取器至少会尝试完成一对 128 字节对齐的行。）Line size of L1 and L2 caches

内存在什么情况下加载到L2/L3？

另见Is L2 line fill always triggered on lookup?

取决于 cache inclusion policy，例如独占外部缓存不会有刚刚加载到 L1d 中的内容的副本，受害者缓存也不会（wikipedia，尽管大型 L3 受害者缓存不完全关联）。在 x86 世界中，Intel 没有使用通常的受害者缓存（Which cache mapping technique is used in intel core i7 processor?），但 AMD 在一些微架构（例如推土机系列）中使用。 POWER 还使用了 L3 受害者缓存。

除了缓存行和 TLB 之外，是否还有其他结构可以产生“缓存局部性”？

是的，DRAM“页面”（行大小）意味着一个页面内的多个缓存未命中可以让 DRAM 控制器避免选择不同的行，而只需从已经打开的行中读取另一列。更改行会增加超出正常成本的 DRAM 延迟。

What Every Programmer Should Know About Memory? 涵盖了 DRAM，以及许多关于缓存和缓存局部性优化的内容，并且仍然具有高度相关性。

此外，如上所述，附近页面的页面遍历可能会更快一些。

一个大/hugepage（例如 x86-64 上的 2MiB）让一个 TLB 条目覆盖整个 2M。

连续高速缓存行的顺序读取（或写入）触发硬件预取器在请求访问之前将这些行拉入 L2（甚至 L1d），从而减少未命中延迟。 （或者，如果循环在 ALU 工作上花费的时间足够长，硬件预取可以跟上其访问的速度，则完全避免未命中。）