第四章 监听协议基础：从MESI到CXL.cache扩展状态
这一章我们聊聊监听协议。你可能会问：“这东西跟 CXL.cache 有什么关系？” 关系大了。多 Socket 环境下的数据一致性，全靠协议状态机兜底。我刚开始接触 CXL 时，也以为只要管好带宽和延迟就行，结果第一版原型就因为状态理解不当，跑出了数据错乱…… 嗯，从那以后我老老实实把 MESI 重新啃了一遍。
4.1 MESI 协议：经典四态回顾
MESI 是缓存一致性协议的基石。它定义了四种状态：Modified、Exclusive、Shared、Invalid。说白了就是告诉每个缓存行：这数据是独享的还是共享的，能不能写？
| 状态 | 含义 | 数据是否有效 | 是否独占 | 是否脏 |
|---|---|---|---|---|
| M | 修改 | 有效 | 是 | 是 |
| E | 独占 | 有效 | 是 | 否 |
| S | 共享 | 有效 | 否 | 否 |
| I | 无效 | 无效 | – | – |
平时看协议文档，状态转换图密密麻麻。但对我来讲，记住两点就够了：写命中时，必须先把其他核心的副本变成 I 状态；读缺失时，如果发现其他核心有 E 或 M 状态，要通过监听总线拿过来。
经验之谈： 我在一个 4-Socket 项目里，遇到过因为某厂商的 CPU 把 E 状态当成 M 来处理，导致写回数据被错误覆盖。最后发现是协议转换逻辑少了一条“E->M 可升级”路径。所以别觉得 E 状态简单，它其实是性能的关键。
4.2 MOESI 与 MESIF：行业变种
为什么需要变种？一个核心想写数据时，如果其他核心全是 S 状态，传统 MESI 必须发总线 Invalid 消息。但有些场景下，我们可以更聪明。
- MOESI：额外引入 Owned 状态。Owned 意味着该缓存行有效且脏，但其他核心可以拥有 S 副本。说白了就是允许“一个写副本 + 多个只读副本”共存。这在某些 AMD 多 Socket 系统里很常见。
- MESIF：额外引入 Forward 状态。MESIF 规定同一数据只能有一个 F 状态的缓存行，它负责回应其他核心的监听请求。减少了总线上的仲裁竞争。Intel 的 QPI 就用这个。
| 协议 | 新增状态 | 核心意图 | 典型使用 |
|---|---|---|---|
| MOESI | Owned (O) | 允许脏数据被共享 | AMD Opteron、某些 ARM 实现 |
| MESIF | Forward (F) | 指定唯一响应者 | Intel Xeon (QPI/UPI) |
避坑指南： 我曾经把 MOESI 的 O 状态当作 S 来用，结果写回时脏数据没被刷新，导致内存和缓存不一致。记住：O 状态的数据必须由拥有方写回内存，其他 S 副本不能直接写回。
4.3 CXL.cache 中的扩展状态
CXL.cache 作为外围设备访问主存的通道，它不能完全照搬 CPU 内的一致性模型。为什么？因为设备端的缓存层次更浅，而且没有同等复杂的监听网络。所以 CXL 定义了自己的一套扩展状态。
CXL.cache 协议栈包含三个主要状态组：
- Cache Line 状态：M、E、S、I 这四态被保留，但增加了 CXL_SnpData 和 CXL_SnpInv 这样的监听事务类型。
- Host 侧状态：主机侧维护一个“监听过滤器”（Snoop Filter），它记录每个 Cache Line 当前被哪个设备持有、持有的是什么状态。
- Device 侧扩展状态：比如 Dirty Shared (DS) —— 设备可以持有脏数据的同时，允许其他设备或主机读共享。这有点像 MOESI 的 O 状态，但更轻量。
你看，CXL 不是在发明新协议，而是把已有的协议变种适配到设备端。我个人习惯把 CXL.cache 的状态机简化成两类：“主机视角”和“设备视角”，分别画两张表。下面这张 SVG 图展示了两者之间的映射关系。
4.4 一致性状态机在多Socket下的关键差异
单 Socket 里，所有核心共享同一个监听总线。多 Socket 下，每个 Socket 有自己的监听过滤器，跨 Socket 的监听请求要走一致性互联（比如 UPI、CXL.io）。这就引入了几个必须注意的地方：
- 监听延迟不对称：本 Socket 监听 1-2 个周期，跨 Socket 可能 20-50 个周期。CXL.cache 设备需要额外的 Credit 管理。
- 状态机需要支持 “Pend” 子状态：当一个监听请求发出后，在响应回来之前，该缓存行处于 “Pending” 状态，不能接受新的访问。我在项目里见过因为这个子状态实现不完整，导致死锁。
- CXL.cache 设备不能做侦听发起方：设备只能被动响应主机的监听，或者主动发起 “Back-Invalidation” 请求（比如需替换缓存行时）。主机侧必须提供对应的 “Snoop Filter” 以跟踪所有远端状态。
踩坑实录： 曾有一次，我在多 Socket 系统上用 CXL 内存扩展卡，发现跨 Socket 写性能暴跌。折腾两天才发现，设备侧的 DS 状态在主机监听过滤器里被错误标记为普通 S，导致每次写之前都要做全局 invalidation。修复映射关系后，性能提升 40%。所以，状态映射的逻辑必须跟 CXL 规范完全对齐，别自己瞎猜。
最后说个小技巧：调试一致性协议时，用硬件 trace 抓出每个缓存行的状态变化曲线，比软件模拟靠谱得多。我自己就常配一套逻辑分析仪，专门看 Snoop Filter 的命中/缺失计数，很快就能定位问题。