CXL 缓存一致性：从概念到实战
缓存一致性，这个词听起来很唬人。说白了，就是让多个设备看到同一份内存数据时，保证大家拿到的都是最新的版本。你想想看，CPU 自己有一级二级三级缓存，加速卡也有自己的本地缓存，如果 CPU 改了某个地址的数据，加速卡还拿着旧的副本在算，那结果肯定错得一塌糊涂。
我在做第一个 CXL 项目的时候，就遇到过这种坑。当时加速卡跑出来的结果时对时错，排查了整整三天，最后发现是缓存一致性的一个状态没处理好。嗯，从那以后我对这块就特别上心。
3.1 CXL 缓存一致性的核心模型
CXL.cache 和 CXL.mem 这两个子协议，负责的就是缓存一致性。它们定义了一套规则，告诉设备之间怎么交换缓存行的所有权和状态。
我个人习惯把 CXL 的一致性模型理解成一个「三方协议」：
- Host（主机）：通常是 CPU 端，拥有内存的最终所有权。
- Device（设备）：比如加速卡、智能网卡，它们可以缓存主机内存的数据。
- 一致性引擎：内嵌在 CXL 控制器里，负责跟踪每个缓存行的状态。
这三方之间通过消息来沟通。设备想读数据？发个 Snoop 请求。设备想改数据？发个 Invalidate 请求。主机要回滚设备的数据？发个 Back-Invalidate。
核心原则：任何时候，最多只有一个设备拥有某个缓存行的「修改权」。
3.2 三个子协议的协作
CXL 把一致性拆成了三个子协议，各管一摊：
| 子协议 | 负责内容 | 我常用的记忆方法 |
|---|---|---|
| CXL.io | 设备发现、初始化、DMA 传输 | 「IO 就是打杂的」— 负责后勤 |
| CXL.cache | 设备发起一致性请求 | 「Cache 是设备出发的」— 从设备视角看 |
| CXL.mem | 主机响应一致性请求 | 「Mem 是主机回的」— 从主机视角看 |
为什么会这样设计？因为 CXL 假设主机内存是「源」——也就是真正的家。设备想访问内存，必须通过一致性引擎向主机打招呼。CXL.cache 就是设备举起的小旗子，CXL.mem 是主机挥回来的手。
我记得有次培训新人，对方总觉得 CXL.cache 和 CXL.mem 是对称的。其实不对。设备只能发 CXL.cache 请求，主机只能发 CXL.mem 响应。两者合在一起，才完成一次完整的数据交互。
3.3 缓存状态模型：MESI 的变体
CXL 的缓存状态基本沿用了经典的 MESI 协议，但因为涉及多个设备，做了一些扩展。这是一个典型的 CXL 一致性缓存状态表：
| 状态 | 含义 | 数据是否有效 | 是否有修改权 | 典型场景 |
|---|---|---|---|---|
| M (Modified) | 已修改且独占 | 是 | 是 | 设备写入了数据，还没有写回主机 |
| E (Exclusive) | 独占且清洁 | 是 | 是 | 设备刚拿到数据，且其他人没拷贝 |
| S (Shared) | 共享且清洁 | 是 | 否 | 多个设备同时读同一行数据 |
| I (Invalid) | 无效 | 否 | 否 | 缓存行被其他设备修改或驱逐 |
这里有个重点：CXL 里多了一个 B 状态（Back-Invalidate）。这个状态在其他协议里不常见，但在 CXL 里特别重要。当主机需要把某个缓存行「回滚」时，会向设备发 Back-Invalidate 消息。设备收到后，必须把本地缓存的数据写回主机，并把状态切到 I。
我建议你在设计设备端的一致性状态机时，一定把 B 状态的优先级排到最高。因为主机发 Back-Invalidate 时，往往意味着内存压力大或者设备占着茅坑不拉屎了，如果不及时响应，可能会导致整个系统 hang 住。
3.4 缓存一致性粒度：64 字节的讲究
CXL 的缓存一致性操作基本都是以 64 字节为单位的。为什么是 64？因为这是当前主流 CPU 的缓存行大小。
但这里面有个细节：设备不一定非要按 64 字节对齐访问。你发送一个 32 字节的请求，CXL 控制器内部会帮你补齐到 64 字节，然后在数据返回后只把你要的那部分给你。
我在项目中遇到过一个问题：设备频繁发送 32 字节的写请求，导致主机端看到大量的伪共享（False Sharing）——就是多个缓存行在同一个缓存行里打架。本来没冲突的数据，因为对齐问题互相 invalidation，性能直接腰斩。解决方式很简单：在设备驱动层做写缓冲，把多个小写入合并成 64 字节的整块写入。
注意：虽然 CXL 支持任意字节长度的请求，但实际硬件实现上，大部分控制器对非 64 字节对齐的访问会做拆分，这会增加延迟和总线上消息的数量。尽量让设备发起 64 字节对齐的一致性请求。
3.5 实战中的几个关键点
3.5.1 状态转换的正确性
- 设备从主机拿到 E 状态后，如果自己偷偷改了数据，必须把 E 升到 M。
- 从 M 状态收到其他设备的读请求，必须先把数据写回主机，再切到 S。
- 从 M 状态收到 Invalidate 请求，必须写回数据后切到 I。
3.5.2 避免死锁
CXL 一致性请求需要用独立的虚拟通道（Virtual Channel），和数据通道分开。如果你让一致性请求和数据传抢夺同一个物理通道，很容易死锁。我曾经在调试日志里看到死锁现场：设备发着 Snoop 请求，等着主机回数据；主机却在等设备空出接收缓冲区……两边死等。
3.5.3 打点监控
建议在每个一致性请求的入口和出口加计数器。我习惯用以下指标来衡量系统健康度：
- Snoop 成功率：有多少请求被直接命中缓存。
- Back-Invalidate 频率：太频繁说明系统存在剧烈的缓存抖动。
- E→M 转换率：如果这个值很高，说明设备频繁修改数据，缓存命中率可能在下降。
3.6 小结
CXL 缓存一致性不是什么玄学。它就是一套规矩：谁可以改、谁可以读、改完告诉谁、读不到找谁。你只要理清了状态机，看懂了消息类型，剩下的就是按照规矩办事。
关于这些知识，我建议大家先对照自己平台上的一致性测试用例，手动画一遍状态转换图。相信我，画完这张图，你对 CXL 的理解就能超过 80% 的工程师。