caching - MESI 协议(protocol)中的 L3$ 角色部分是什么

Question

我想在 intel Broadwell 中了解 MESI 的更多细节。

假设一个 cpu 插槽有 6 个核心 core 0 到 core 5 ，
他们每个人都有自己的 L1$ 和 L2$ 并共享 L3$ ，
共享内存中有一个 var X ， x 位于缓存行中
称为 XCacheL ，以下是我的问题的详细信息:

T1:核心 0 和核心 4 和核心 5 有 x = 100 和 XCacheL
是 小号 由于 3 核具有 XCacheL 的副本，因此处于 Hared 状态。

T2 : 核心 0 需要修改 x ，所以核心 0 广播无效信号，核心 4 和核心 5 接收到信号
，使他们的 XCacheL 副本无效，Core 0 将 x 修改为 200
XCacheL 状态现在是 手机 修改。

T3:核心 4 需要读取 x，但其 XCacheL 副本在 T2 中无效，因此它会触发读取未命中，将发生以下情况:

● Processor makes bus request to memory
● Snooping cache puts copy value on the bus
● Memory access is abandoned
● Local processor caches value
● Local copy tagged S
● Source (M) value copied back to memory
● Source value M -> S

所以在 T3 之后，XCacheL 是核心 0 和核心 4 状态: 小号 和 我 在核心 5 中验证，并且
L3$ 和主内存具有最新的有效 XCacheL 。

T4:核心 5 需要读取 x ，因为它的 XCacheL 副本是 我 nvalidated 在 T2 中，但是这个 monent XCacheL 有
L3$ 中的正确副本，核心 5 是否需要像核心 4 那样触发读取未命中？!

我的猜测是:不需要，因为 L3$ 有有效的 XCacheL，
因此核心 5 可以达到 L3$ 并在核心 5 中从 L3$ 到 L1$ 获得正确的 XCacheL，因此核心 5 不会触发读取未命中。

Answer 1

没错，在您的 T4 步骤中，核心 #5 的负载将在 L3 中达到，因此不会发生内存访问。核心#5 获得该行的另一个副本，处于共享状态。

对于像 Broadwell 这样所有内核共享对片上 DRAM Controller 的访问的 CPU，您的步骤顺序是零意义的。

环形总线连接核心(每个核心都有一片 L3 缓存)和系统代理(PCIe 链接和与其他核心的连接)和归属代理(内存 Controller )。见 https://en.wikichip.org/wiki/intel/microarchitectures/broadwell_(client)#Die_Stats有关显示环形总线的框图。

单个内核不直接驱动“内存总线”，甚至不驱动 2 或 4 条 DRAM 总线之一。内存 Controller 仲裁对 DRAM 的访问，并有一些缓冲来重新排序/组合访问。 (所有访问内存的东西都经过它，包括 DMA，所以它可以做任何它喜欢做的事情，只要它给出以某种合理的顺序发生的加载/存储的外观。)

加载请求在 L3 缓存未命中之前不会发送到系统代理。见 https://superuser.com/questions/1226197/x86-address-space-controller/1226198#1226198有关四核桌面的说明(它更简单，只是将内存 Controller 连接到系统代理，使其与 CPU 集成内存 Controller 之前的北桥完全一样。)

由于 Broadwell 使用包含 L3 缓存，L3 标签可以告诉它哪个(如果有)核心具有修改或独占副本，即使 L3 本身中的行不可共享。 (即一行的数据在 L3 中可能是无效的，但标签仍在跟踪哪个核心有私有(private)副本)。见 Which cache mapping technique is used in intel core i7 processor?

这让 L3 标签充当窥探过滤器以减少广播。