x86平台Intel与AMD缓存包容性策略差异及AMD非包容性L3原因探究

缓存包容性的实测与文档验证 #

AMD 17h系列（Zen至Zen2）缓存特性 #

了解到AMD 17h系列处理器（Zen至Zen2，后续世代可能也是如此，但笔者并不熟悉）的L2缓存对L1缓存具有包容性，而L3缓存则不具备。

遗憾的是，笔者无法从AMD手册中获取更多细节，仅第2卷（Rev3.41）提及相关内容，表述为：

L2缓存可以是排他性的，即不缓存L1缓存中已有的信息。相反，包容性L2缓存会保留L1缓存信息的副本。

不过，这一点已在笔者的Zen机器上通过CPUID读取结果得到验证：

$ cpuid # 以下输出Core::X86::Cpuid::CachePropEdx0-3属性
 --- cache 2 ---
[...] 
      cache inclusive of lower levels = true
--- cache 3 ---
[...] 
      cache inclusive of lower levels = false

Intel CPU缓存特性 #

另一方面，Intel CPU的LLC（L3）具有包容性，这在其架构开发者手册的所有卷册中多次提及（有趣的是，Intel也有部分处理器不采用包容性L3缓存，如Skylake Server，详见优化参考手册文档#248966-049US第77-80页）

这一点也在笔者的Kaby Lake机器上通过CPUID读取结果得到验证：

$ cpuid # 以下输出确定性缓存参数叶
--- cache 2 ---
[...] 
      inclusive to lower caches          = false
--- cache 3 ---
[...] 
      inclusive to lower caches          = true

此外，2010年的一份课程幻灯片指出："AMD处理器倾向于使用排他性缓存；Intel处理器倾向于使用包容性缓存"

Intel包容性L3的作用机制 #

笔者理解（若有混淆之处深表歉意），在Intel的实现中，L3充当全局目录/替代监听算法，核心的缓存行请求可通过L3维护的附加信息判断该行是否存在于其他核心中，因为L3对所有这些行具有包容性

正如Intel优化手册所述：

B.4.5.3 全局队列监听事件

来自核心、远程封装或I/O Hub的缓存行请求由GQ处理。当非核心单元收到某个核心的缓存行请求时，GQ首先检查L3以确定该行是否在封装内。由于L3具有包容性，可快速得出结论。若该行存在于L3且归请求核心所有，则可直接从L3向核心返回数据。若该行被多个核心使用，GQ将监听其他核心以查看是否存在修改后的副本。若存在，则更新L3并将该行发送至请求核心。

此外，优化手册第2卷文档编号356477-002US指出：

LLC对其上方的所有缓存级别具有包容性——核心缓存中包含的数据也必须存在于LLC中。LLC中的每个缓存行都包含一个指示位，表明哪些核心的L2和L1缓存中可能存在该行。若LLC中的指示位显示其他核心可能持有目标行且其状态可能已修改，则还需查询这些核心的L1数据缓存和L2缓存。若无需从其他核心缓存获取数据，则该查询称为“clean”；若需从其他核心缓存获取修改后的数据并传输至加载核心，则称为“dirty”。

在同一手册的Nehalem章节中提到：“采用共享、包容性L3的新型缓存层次结构，以减少监听流量。”以及“共享L3缓存为回写式且具有包容性，因此存在于L1数据缓存、L1指令缓存或统一L2缓存中的缓存行也存在于L3中。L3旨在利用其包容性减少处理器核心之间的监听流量”，诸如此类。

技术疑问 #

AMD决定不采用包容性L3缓存的原因是什么？这是否意味着其处理器核心间的“监听流量”远多于Intel处理器？考虑到AMD新一代处理器的LLC容量（如3D V-Cache）并不匮乏，这仅仅是Intel和AMD在缓存一致性算法组织上的偏好差异吗？还是说Intel才是特例？

内容的提问来源于stack exchange，提问作者Andriy Sultanov