缓存一致性基础：MESI协议、CXL.cache工作原理
聊到 CXL.cache，绕不开的核心就是缓存一致性。说白了，就是多个计算单元（CPU、加速器、GPU）共享同一块内存时，如何保证大家读到的是最新数据。我在刚接触异构计算时，总觉得这不过是个协议问题，直到有一次项目里因为缓存没同步，调试了整整两天才发现是状态机跑飞了。嗯，从那以后，我对这块再也不敢马虎。
这一节我们就从最经典的 MESI 协议讲起，再看它如何映射到 CXL.cache 的请求模型里。理解了这两者的关系，后续的测试场景设计你才能做到心里有数。
为什么需要缓存一致性？
先看一个简单场景：CPU 核 A 写了一个变量 x = 1，数据还在自己的 L1 Cache 里，没写回主存。此时加速器核 B 读了 x，拿到的是旧值 0。问题就来了——同一个内存地址，在不同缓存副本里出现了分歧。
在多核 CPU 的片内缓存场景，MESI 协议解决了这个分歧。到了 CXL 这种跨芯片的互联场景，CXL.cache 在 MESI 基础上做了扩展，让 Host（主机 CPU）和 Device（加速器/内存扩展）的缓存层能协同工作。你以为只是协议栈里多了一层？其实这里坑不少，我后面会说到。
MESI 协议详解
MESI 是四个状态的缩写：Modified（已修改）、Exclusive（独占）、Shared（共享）、Invalid（无效）。每个缓存行在任何时刻必居其一。
| 状态 | 本地数据是否有效 | 数据与主存是否一致 | 其他核是否有副本 |
|---|---|---|---|
| M (Modified) | 是 | 否（已修改，未写回） | 否 |
| E (Exclusive) | 是 | 是 | 否 |
| S (Shared) | 是 | 是 | 是（至少一个其他核） |
| I (Invalid) | 否 | - | - |
你可以这么理解：E 状态是最理想的位置——数据干净、独占、随时可写不通知别人。M 状态的数据最「脏」，只有你自己有最新版，写回主存前谁都不能碰。S 状态是大家一起读，但谁想写就得先升级成 M。I 状态嘛，就是缓存行「作废」了，必须重新从下级存储拉。
状态转换的核心逻辑
状态转换由本地读写请求或远端 snoop 请求触发。我个人习惯把关键路径记成三组：
- 读未命中 → 填充：I → E（独占填充）或 I → S（共享填充），取决于总线是否检测到其他副本。
- 写命中 → 脏化：E → M（直接改）、S → M（先发 invalidation，再改）。
- 远端访问 → 失效/写回：M → S（写回并共享）、M → I（写回且丢弃）、S → I（直接失效）。
我曾经在一个测试用例里发现，Device 频繁写某条缓存行，导致 Host 侧的 S 状态行不断被 invalidate，性能直接腰斩。后面加了个写聚合的优化，才把吞吐拉回来。你看，理解状态转换对性能分析有多关键。
CXL.cache 的工作原理
CXL.cache 是 CXL 协议中负责缓存一致性的子协议。它允许 Device（比如加速器或内存扩展器）以「缓存代理」的身份，向 Host 发起读写请求，并参与 MESI 的状态协商。
CXL.cache 定义了三种核心请求类型，我习惯把它们和 MESI 转换对应着记：
| CXL.cache 请求 | 方向 | 语义 | 对应 MESI 转换 |
|---|---|---|---|
| RdOwn | Device → Host | 读数据，并要独占权（准备后续写） | I → E |
| RdShared | Device → Host | 读数据，允许其他核保留副本 | I → S |
| WrLine | Device → Host | 写一整行缓存，要求其他副本失效 | E → M / S → M |
你看，WrLine 其实就是「我要写，你们都让开」的指令。它背后会触发 Host 侧做 snoop，把其他核的 S 或 E 状态行 invalidate 掉，然后 Device 才能安全地写入。
状态转换与 CXL.cache 的映射
下面这张图梳理了 MESI 的四个状态和 CXL.cache 请求之间的映射关系。你看箭头上的标签，就是 Device 发起的典型请求。