Ice Lake 的 48KiB L1 数据缓存的索引是如何工作的？

Question

英特尔手动优化（2019 年 9 月修订版）显示了用于 Ice Lake 微架构的 48 KiB 8 路关联 L1 数据缓存。

^{1软件可见的延迟/带宽会因访问模式和其他因素而异。}

这让我感到困惑，因为：

• 有 96 组（48 KiB / 64 / 8），不是二的幂。
• 集合的索引位和字节偏移的索引位相加超过 12 位，这使得4KiB 页面无法使用便宜的 PIPT-as-VIPT-trick。

总而言之，缓存的处理成本似乎更高，但延迟仅略有增加（如果确实如此，则取决于英特尔对该数字的确切含义）。

有一点创造力，我仍然可以想象一种快速索引 96 组的方法，但第二点对我来说似乎是一个重要的突破性变化。

我错过了什么？

Answer 1

优化手册是错误的。

根据CPUID说明，关联性为 12（在 Core i5-1035G1 上）。另请参阅uops.info/cache.html和en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(client)。

这意味着有 64 个集合，这与之前的微架构相同。

Answer 2

处理器系列的优化手册和数据表（第 2.4.2 节）都提到 L1 数据缓存是 8 路关联的。另一个来源是InstLatx64，它为包括 Ice Lake 处理器在内的许多处理器提供cpuid 转储。以i7-1065G7的转储为例

CPUID 00000004：1C004121-02C0003F-0000003F-00000000 [SL 00]

缓存信息可以在cpuid叶 0x4 中找到。英特尔 SDM 第 2 卷讨论了如何解码这些字节。EBX 的第 31 - 22 位（左起第二个）表示路数减一。这些二进制位是 1011，也就是十进制的 11。所以cpuid说有12种方式。我们可以从这里获得的其他信息是，L1 数据缓存大小为 48KB，缓存行大小为 64 字节，并使用简单的寻址方案。因此，根据cpuid信息，地址的第 11-6 位表示缓存集索引。

那么哪个是正确的呢？优化手册可能是错误的（这不是第一次），但cpuid转储也可能有问题（这也不是第一次）。好吧，两者都可能是错误的，但从历史上看，这种可能性要小得多。此处cpuid讨论了手册和信息之间差异的其他示例，因此我们知道这两个来源都存在错误。此外，我不知道任何其他英特尔来源提到 L1D 中的方式数量。当然，非英特尔来源也可能是错误的。

有 96 组的 8 路将导致不寻常的设计，并且在优化手册中仅提及一个数字的情况下不太可能发生（尽管这并不一定意味着缓存必须具有 12 路）。这本身使得手册在这里更有可能出错。

幸运的是，英特尔确实在规范更新文档中记录了其处理器中的实现错误。我们可以查看 Ice Lake 处理器的规格更新文档，您可以在此处找到。cpuid那里记录了两个错误：

CPUID TLB 信息不准确

我已经在我关于从 Intel CPUID 结果中理解 TLB 的回答中讨论了这个问题。第二个错误是：

CPUID L2 缓存信息可能不准确

这与您的问题无关。

规范更新文档提到了一些cpuid错误这一事实强烈表明cpuid叶 0x4中的信息已经过英特尔验证并且是准确的。所以在这种情况下，优化手册（和数据表）可能是错误的。