4. CXL.cache 事务类型与操作归纳总结

做 CXL 一致性调试，最烦的就是被海量事务日志淹没。我自己刚接触那会儿，对着几百兆的 trace 不知道怎么下手。后来我习惯先把事务分个类，把主要矛盾揪出来。

说白了，CXL.cache 的事务类型就那么几大类。你想想看，缓存一致性嘛，核心动作无非是：请求数据、写回数据、监听别人有没有修改、还有各种元数据管理。

下面我按自己的理解，把这几类事务给你们理一遍。记得我在一个多芯片互联项目里，就是因为对某类事务的理解不到位，差点把整个系统搞挂……嗯，今天正好把这部分补上。

4.1 事务类型全景

我先给个大表，把 CXL.cache 的主要事务类型摆出来。这张表是我自己长期排查问题用的，你们可以当速查手册。

4.2 核心事务深度解读

4.2.1 读请求三兄弟

RdUnique、RdCurrent、RdShared，这三兄弟很容易搞混。我刚开始时就踩过坑——该用 RdUnique 的地方用了 RdShared，结果数据是读到缓存里了，但想修改时发现冲突没处解。

区别在哪里呢？

• RdUnique：我要改数据！其他缓存里如果有副本，全都给我失效掉。这个事务会触发监听失效。我在项目中看到过某设备连续发了十几次 RdUnique 请求同一行，结果监听风暴把总线冲垮了。当时排查了好久才发现是软件层分配策略出问题了。
• RdCurrent：我就是看看，不改你。拿到最新数据就行，不用改状态。适用于只读监控。
• RdShared：我读了你也可以在缓存里保留副本，互相不干涉。但有问题——如果其他设备在你读完之后改了行，你还没被通知到，那一瞬间你会持有过期数据。

4.2.2 写回与冲刷

WrBack 是最常见的写操作。但要注意，WrBack 写完了，行在设备端的状态变成 Invalid，而不是保持 Modified 或者 Shared。你想想看，既然数据都还给主人了，那本地留着也没意义。

Flush 则更彻底——先把脏数据写回（如果有），再把本地缓存行清掉。我记得有个性能优化案例，设备端频繁写回小粒度数据，每次写回都带了大量的元数据开销。后来改成批量写回加 Flush，总线上事务量降了 40%。

4.2.3 监听与反向失效

Snoop 事务是由主机发起的，目的是检查或修改其他缓存的副本状态。比如，主机收到一个 RdUnique 请求，它需要先发 SnoopInv 给所有其他设备，确保没有其他副本。

Back-Invalidation 这个比较有意思。它是主机主动发起的，让设备端缓存行失效，而且不需要请求方发起任何读操作。我当初在一个内存池化项目中用这个机制做过热迁移——把设备缓存逐行 Back-Inv 掉，然后调整映射关系，基本无感完成切换。

4.3 操作流程归纳

把这些事务组合起来，就构成了 CXL.cache 的操作流。我总结成几个典型场景的流水线，你们可以直接对照日志看。

1. 读后修改（Read-Modify-Write）
   RdUnique → SnoopInv(发给其他设备) → 数据回本 → 本地修改 → WrBack
2. 只读共享（Read-Only）
   RdShared → 数据回本 —— 不需要 WrBack，因为没人改
3. 监听失效触发更新
   主机发 SnoopInv → 目标设备查本地状态 → 如果是 Modified 则写回 → 失效
4. 设备端缓存冲刷
   Flush/Clean → 脏数据写回 → 标记无效
5. 主机主动收回（热迁移场景）
   Back-Inv × N → 设备缓存全清 → 内存映射切换

4.4 事务冲突常见模式

下面这张 SVG 图，是我自己画的事务分类与冲突对照图。你们排查一致性冲突时，可以用它来定位“哪个事务跟哪个事务容易打架”。

4.5 总结

CXL.cache 的事务类型看起来多，但核心逻辑不复杂。记住三组关键词：请求(读/写)、监听(失效/读)、冲刷(写回/清理)。排查冲突时，先定位事务大类，再看具体的操作组合。

嗯，这一块如果你们在实际项目里遇到特别诡异的 trace，不妨把这个表格和 SVG 摆出来，一行一行对照。我个人就是这样练出来的，现在看 CXL 日志基本上能一眼看出问题所在。