CXL.cache 一致性模型基础归纳总结
说起 CXL.cache，很多人第一反应就是“跟 MESI 差不多嘛”。
其实，差不多的只是底层的状态机思想，真上了硬件，你会发现差距还挺大。
我个人习惯把一致性模型拆成三块来理解：状态、事务、域。
下面我结合项目里踩过的坑，给你捋一遍。
核心状态：从 MESI 到 CXL 的扩展
经典的 MESI（Modified、Exclusive、Shared、Invalid），在 CXL.cache 里基本都能找到对应。
但 CXL 多了几个特殊状态，用来处理 Device 侧和 Host 侧之间的异步操作。
| CXL.cache 状态 | 对应 MESI | 含义 |
|---|---|---|
| Hwd（Host-owned dirty） | Modified | Host 缓存拥有且数据已修改，Device 不能直接读 |
| Hwc（Host-owned clean） | Exclusive | Host 独享且干净，但 Device 可以通过特定事务获取 |
| Dwd（Device-owned dirty） | — | Device 缓存修改且未写回 Host，这是 CXL 特有的 |
| Shared | Shared | 多方共存，都只读 |
| Invalid | Invalid | 无有效副本 |
你可能注意到了，CXL 把 “Owner” 分成了 Host 和 Device 两大类。
我当初刚接触时总搞混，后来记住一句话：“谁修改，谁就是 Owner，直到写回去”。
事务类型与通道
CXL.cache 协议定义了两种主要请求方向：
- H2D（Host to Device）：Host 发起的监听、冲刷、数据回写请求。
- D2H（Device to Host）：Device 发起的读、写、非监听写回请求。
这里有个容易踩的坑：
我曾经在调试一致性冲突时，发现 Device 发了个读请求，但 Host 没回响应。
查了半天，原来 Device 侧忘记在请求中携带 Coherence ID —— 这个 ID 是 CXL 用来关联请求和响应的关键字段。
一致性域与全局观察
CXL 的一致性域比传统 NUMA 更复杂。
一个典型的场景是：多个 Device 同时访问同一块内存。
这时必须保证所有缓存副本在逻辑上看到同一个写顺序。
怎么做？
CXL 引入了 全局观察点（Global Observation Point） 的概念。
你可以把它想象成一个仲裁中心，所有写操作在它那里排好队，再广播给其他缓存。
关键指标：
- 写操作的全局可见性延迟通常 < 50ns（在理想互连下）
- 一致性冲突发生时，回退策略有“写失效”和“写更新”两种，CXL 默认用写失效
- 每个 Device 最多支持 32 个未完成的一致性事务（不同 CXL 版本有差异）
一张图看懂 CXL.cache 一致性模型
下面这张图展示了 Host、Device、Cache 之间的状态流转及 Snoop 路径。
你仔细看，Dwd 状态只有 Device 一侧有，这是 H2D 回写触发后才会消失。
后来养成个习惯：每次 D2H 写回后，立马检查 Host 侧是否更新了 Cache 状态。这个检查帮我抓住了至少 3 个一致性 bug。
避坑指南：一致性冲突的常见根因
- 状态机翻转冲突：Device 在 Dwd 状态下收到 Host 的 Snoop 读请求，却直接回 ACK 不带数据。正确的做法是先写回再响应。
- Coherence ID 重复使用：两个请求用了同一个 ID，导致响应乱序。我经历过一次线上事故，就是因为驱动层没清空 pending list。
- Snoop 超时：协议规定 Snoop 响应必须在规定周期内返回。如果你的 Device 缓存很大，需要提前预判并进行 partial snoop。
- 写更新与写失效混用：CXL 允许 Device 自主选择写失效或写更新，但同一个域里大家得统一。混用了就会看到数据不一致——嗯，我当年就因为这个调了三天。
好了，这一章的核心就是：状态是基础，事务是动作，域是边界。
搞懂了这三样，后面排查冲突就顺手多了。