3. Cache 一致性协议（MESI/MOESI）与 CXL 的关系
讲到 CXL.cache，绕不开的就是 Cache 一致性协议。说白了，CXL 就是为了解决多主机之间缓存同步问题而生的。它的底层逻辑，很大程度上借鉴了我们非常熟悉的 MESI 和 MOESI 协议。
我在刚接触 CXL 时，第一反应是：“这不就是把 CPU 核间的那套一致性协议搬到设备上了吗？” 后来仔细研究，发现还真不完全是这样。CXL 只是用了类似的状态机，但操作层面做了很多简化。
3.1 MESI 协议在 CXL 下的映射
我们先回顾一下经典的 MESI。它定义了四种状态：Modified、Exclusive、Shared、Invalid。在 CXL.cache 里，设备端的 Cache Line 也得遵守这套规则。嗯，为了方便理解，我习惯把这四种状态看作是设备对某块数据的“权限等级”。
| MESI 状态 | CXL 下的含义 | 本地 Cache 权限 | 远端响应 |
|---|---|---|---|
| M (Modified) | 设备独占并修改了数据 | 可读可写，数据脏 | 必须写回才能共享 |
| E (Exclusive) | 设备独占但数据干净 | 可读可写，数据未改 | 清理后可直接共享 |
| S (Shared) | 设备拥有只读副本 | 仅可读 | 允许多个 S 存在 |
| I (Invalid) | 设备无有效数据 | 无权限 | 需要重新获取 |
我记得之前排查一个 GPU 显存一致性问题时，发现设备老是发 SnpData 请求。后来一查，原来是设备端把 Shared 状态当成 Exclusive 来用了。打个比方，设备认为自己有独享权，但实际上主机那边已经把数据改掉了。这个坑我踩过一次，后来就特别注意状态机的初始赋值。
3.2 MOESI：多出来的 O 状态有什么用？
MOESI 比 MESI 多了一个 O (Owned) 状态。为什么会有 O？因为在某些场景下，我们不想让数据写回内存，但又想共享给其他请求方。说白了，O 状态允许一个拥有 Shared 副本的 Cache 承担“数据提供者”的角色。
我经手的一个存储加速项目中，设备端缓存的命中率总是上不去。调试后发现，设备把线状态标记为 M，但很少写回。换成 O 状态后，主机可以直接从设备拿数据，省掉了一次内存访问，延迟降了 30%。
3.3 CXL.cache 的操作与协议状态机
CXL.cache 定义了一组操作，这些操作会驱动状态机切换。我用表格整理一下最常见的关系：
| CXL.cache 操作 | 方向 | 典型状态转换 |
|---|---|---|
| RdShared | 设备→主机 | I → S |
| RdOwn | 设备→主机 | I → E 或 I → M |
| WrLine | 设备→主机 | E → M 或 I → M |
| WrLineI | 设备→主机 | E → I 或 M → I |
| SnpData | 主机→设备 | M → S 或 E → S |
| SnpInv | 主机→设备 | M → I 或 S → I |
为什么会有这么多操作？因为 CXL 的请求类型和 CPU 是不完全一致的。CPU 内部可能是用 Load/Store 来驱动状态机，但 CXL 设备用的是预定义的请求包。
举个例子： 设备发一个 RdOwn，主机返回数据的同时会把该线在其他所有设备上的副本都失效掉。这个动作相当于一次独占获取。我在验证阶段发现，这个请求如果发得太频繁，会导致主机侧 snoop 风暴。你看看，性能就崩了。
3.4 常见一致性冲突：状态机检查清单
工作中排查冲突，我一般会按优先级检查以下三点：
- 状态机是否完整？ 设备端的 cache line 是否对所有合法操作都定义了状态转换？缺状态转换会导致卡死在某一状态。
- 响应是否超时？ 主机发了 SnpData，设备必须在规定时间（通常几百纳秒）内响应。我曾经遇到过设备处理中断太慢，导致一致性协议握手失败。
- Invalid 状态下的请求是否延迟？ 如果设备频繁地在 I 状态下发起请求，且请求延迟很大，那就说明预取策略有问题。说白了，设备应该提前把需要的数据拉成 S 或 E，而不是现用现查。
3.5 状态机与冲突排查流程图
下面我画了一张图，帮你理清从 CXL 请求到 MESI 状态转换的流程，以及每一步可能出现的冲突点。
所以我建议： 写状态机时，用表格把所有合法输入都列出来，确保没有遗漏。CXL 的状态机比 CPU 内部的简单，但越简单越容易因为粗心而出错。
3.6 小结
总结一下，MESI/MOESI 协议是 CXL.cache 的理论基础。但 CXL 把它简化成了请求-响应模型，去掉了复杂的互联总线细节。理解状态机，不是让你去背状态，而是要明白每个操作背后的权限变化。我个人的排查经验是：先看状态转换是否合法，再看响应是否及时，最后查预取策略是否合理。这三步走完，90% 的一致性冲突都能定位。