企业官网建设流程全解析

刚开始接触 CXL 的时候，我也被一堆缩写绕晕过：CXL.io、CXL.cache、CXL.mem、Type 1/2/3、CEDT、CFMWS、HDM，文档翻了几十页还是不知道这东西在机房里到底长什么样。后来真正在几台支持 CXL 的服务器上把内存扩展卡插上去、在系统里枚举出来、把一块远端内存挂成 NUMA 节点跑完 benchmark，才算把这套东西串起来了。这篇就按我自己的理解路径来写：先讲清 CXL 是什么、为什么会出现，再把协议族和设备类型拆开，然后落到 Linux 上怎么把设备认出来、把内存用起来，最后是我踩过的坑和排查顺序。

CXL 全称 Compute Express Link，是一套跑在 PCIe 物理层之上的缓存一致性互连协议。它要干的事说起来很简单：让 CPU 之外的加速器、内存扩展设备能够以接近本地的语义访问主机内存，同时让主机也能把设备上的内存当成自己内存空间的一部分来用。这套语义的核心是“一致性”——设备读到的数据不会比 CPU 手里的旧，CPU 也不会读到设备改之前的脏值。对做异构计算、做大内存数据库、做内存池化的人来说，这是把“外挂设备内存”从二等公民提升到接近一等公民的关键一步。下面这些内容适合已经了解 PCIe 基础、想搞清楚 CXL 到底能干什么以及怎么上手的读者，也尽量给刚入门的朋友留了足够的铺垫。

1. CXL 究竟在解决什么问题

1.1 从“内存墙”和“加速器墙”说起

过去十几年算力涨得比内存带宽和容量快得多，这个剪刀差就是常说的内存墙。单机内存插槽数量受主板布线和信号完整性限制，一条 DDR 通道挂满也就那么多，容量上不去，带宽也被通道数锁死。当业务需要几 TB 级内存做缓存、做图计算、做内存数据库时，纵向扩容很快就撞到天花板，横向拆分成多机又会引入网络往返和序列化开销，延迟从百纳秒级跳到微秒级，很多场景直接受不了。

另一堵墙在加速器侧。GPU、FPGA、各类专用加速卡要访问主机内存，走的是 PCIe 上的 DMA：驱动在主机侧准备好缓冲区，设备发起 DMA 读写，主机 CPU 并不知情。数据一致性全靠软件在驱动里做同步，稍微写错一个 fence 就是脏读或者丢数据。这套模式对简单的数据搬运够用，但对细粒度、非规则、需要频繁在 CPU 和加速器之间来回访问的负载就很别扭——比如图遍历、稀疏矩阵、指针追逐型算法，每次访问都可能是几十个字节，靠 DMA 整块搬完全不划算。

CXL 就是冲着这两堵墙来的。它在 PCIe 的物理链路上加了缓存一致性的语义，让设备可以带着一致性去访问主机内存，也让主机可以像访问自己内存一样访问设备上的内存。你可以把它理解成给 PCIe 装了一套“共享内存”能力，而不只是“数据传输”能力。

1.2 为什么不用现成的方案凑合

有人会问，CCIX、OpenCAPI 这些前辈不也是干这个的吗，为什么最后是 CXL 站住了？还有更实际的问题：为什么不用 RDMA 做远端内存，或者干脆用非易失内存条？

先说 RDMA。网络路径的延迟基本在微秒量级，即便同一台机器里用高速网卡做 loopback，也躲不开协议栈和网卡的处理开销。而内存访问的语义要求是百纳秒级，差一个数量级，很多算法就没法直接跑。另外 RDMA 是显式的消息语义，代码要改写成 verbs 风格，存量程序没法无感迁移。

再说本地 DIMM。非易失内存条确实是扩容手段，但它占的还是主板上的内存插槽，物理上限没变，而且价格和容量密度并不总是划算。CXL 的价值在于把扩容这件事从“插槽”解耦出来，走标准 PCIe 连接器和线缆，可以一块卡、一个机箱、甚至一个机架背板上的池子。

还有一类方案是在加速器内部做本地内存加软件管理，比如把数据分片放设备显存里，CPU 只做控制。这类方案在规则负载上很有效，但对需要 CPU 和加速器真正共享同一份数据结构的场景，软件管理的复杂度会失控。一致性的价值就是在这些地方体现出来的：硬件帮你保序，你少写一半同步代码，还少了一堆隐蔽的 race condition。

1.3 一句话说清它的定位边界

我给 CXL 的定位是：它不是一个新总线，而是 PCIe 的一致性扩展层。物理层、链路训练、连接器、热插拔这些全部复用 PCIe 生态，这决定了它的成本和部署门槛不会太高；而它在事务层上分出了三个子协议，分别对应“配置与 DMA”“设备缓存主机内存”“主机访问设备内存”三件事。

这句话很重要，因为它解释了 CXL 的一堆设计取舍。比如为什么 CXL 设备必须先枚举成 PCIe 设备才能工作，为什么出问题时要先看 lspci 再看 CXL 子系统，为什么交换机、重定时器、线缆质量会直接影响 CXL 内存能不能稳定上线。把它当成“PCIe 上加了一层”，很多现象就顺了。

另外要强调一点：CXL 不是要取代 DDR 内存，也不是要取代网络。它填的是本地内存和网络之间的那一层——比本地慢一些但比网络快一个量级，比本地贵一点但比堆主板插槽灵活得多。想清楚这个位置，就不会对它有不切实际的期待。

2. 三个子协议与三种设备类型

2.1 CXL.io、CXL.cache、CXL.mem 各管什么

这是 CXL 最核心的概念切分，理解了这三者，后面所有内容都能挂上去。

CXL.io是基础，几乎所有 CXL 设备都必须实现。它本质上就是 PCIe 的事务层：设备枚举、配置空间读写、基地址寄存器映射、DMA、中断、错误上报，全部走这条路。你可以把它当成“CXL 设备作为 PCIe 设备的那一面”。没有 CXL.io，操作系统连设备都发现不了。

CXL.cache解决的是“设备想看主机内存”的问题。设备可以向主机发起读写请求，主机侧的一致性代理负责维护设备缓存行的状态，必要时向设备发 snoop。这条路径的请求粒度很小，典型是 64 字节缓存行，目标是把设备侧的缓存做得像 CPU 核心里的一级缓存那样参与一致性协议。

CXL.mem解决的是“主机想看设备内存”的问题。主机 CPU 发出普通的内存读写，经由 CXL 主机桥转成 CXL.mem 事务送到设备，设备侧的内存控制器完成访问再返回。对操作系统来说，这块内存就是一段物理地址空间，可以被描述成 NUMA 节点，可以被分配器用，可以被进程访问，和本地 DDR 在软件视角上没有本质区别，区别只在延迟和带宽的数字上。

三者组合起来的关系可以这样记：CXL.io 管控制面，CXL.cache 让设备读主机，CXL.mem 让主机读设备。设备能实现哪几个，决定了它属于哪种类型。

2.2 Type 1、Type 2、Type 3 的划分逻辑

这套分类不是为了考试，而是直接决定驱动怎么写、系统怎么配。

Type 1是“没有本地内存的加速器”，只实现 CXL.io 和 CXL.cache。典型例子是智能网卡、某些固定功能加速器。它的诉求是让自己的片上缓存和主机内存保持一致，省掉显式的数据搬运。注意它没有 CXL.mem，所以主机不能访问它的内存——它压根没有可供主机访问的大块内存。

Type 2是“带本地内存的加速器”，三个协议全上。GPU、FPGA、带片上高带宽内存的加速卡属于这一类。它既希望自己的缓存和主机一致（CXL.cache），又希望主机能直接访问它的大块本地内存（CXL.mem）。这是语义最完整、也最难实现的一类，硬件一致性逻辑的复杂度最高。

Type 3是“纯内存扩展设备”，实现 CXL.io 和 CXL.mem，不做 CXL.cache。它就是一块挂在 PCIe 上的内存条，主机把它当内存用，它自己不去主动缓存主机内存。目前市面上能买到、能测到的 CXL 产品，绝大多数是 Type 3，因为它的实现难度最低、价值最直接——扩容内存容量。

注意：Type 3 设备不做 CXL.cache，意味着它不会主动去缓存主机内存行，这简化了一致性逻辑，但也意味着主机对它的访问是单向的“主人访问外设内存”模式。选型时别指望它能反向加速主机侧的缓存。

2.3 一致性是怎么维持的

一致性是 CXL 最容易被含糊带过、又最影响可用性的部分。原理上它复用了经典的多核缓存一致性思路，只是把参与方从 CPU 核心扩展到了设备。

主机侧有一个统一的一致性代理，通常集成在 CPU 的内存控制器或主机桥里，负责维护它管辖的物理地址的一致性状态。设备侧也有对应的代理，管理自己缓存行的状态。当设备想读主机内存时，请求送到主机代理，代理判断自己手里的副本是不是最新的，必要时向其他缓存持有者发 snoop，然后把数据回给设备的同时把状态转换好。反过来，主机要访问设备内存时，走的是另一条路径，因为 Type 3 设备的内存只归主机访问，不需要设备间的一致性协商，逻辑简单很多。

这里有个容易踩的认知坑：CXL 的一致性是有范围的，不是“全网一致”。它保障的是同一个一致性域内、主机和设备之间的顺序与可见性。跨主机、跨机箱的共享内存要靠协议更高层的机制来解决，CXL 3.0 引入了内存共享的能力，但那是另一套用法，需要软件配合，不是插上就自动共享。

工程上还要注意，一致性逻辑要靠 BIOS 和固件正确配置才能打开。很多“设备识别到了但性能极差”的案例，根因就是固件里的一致性相关选项没开对，或者 CXL 解码窗口没有正确映射到系统地址空间。这一层没有配置好，你在操作系统里怎么调都白搭。

3. 版本演进与能力边界

3.1 1.0 和 1.1：把路先修通

最早的两版基于 PCIe 5.0 的物理层，定义了三个子协议的基本框架，主要解决“单机内直连”的场景：一块卡插在主机的一个 PCIe 槽上，或者通过简单的背板连接。1.1 相比 1.0 补齐了不少细节，包括更完整的 RAS 能力、设备侧的一致性支持、以及一些链路和协议层的修正。这一代的产品形态是点对点，拓扑非常简单。

这一代的意义是验证了可行性，但限制也很明显：没有交换能力，一块卡只能连一个主机，不能热插拔，不能做池化。你去翻这一代的规范，会发现它在“多设备组网”上几乎是空白。

3.2 2.0：交换机、池化和热插拔

2.0 是一次大跨步，核心新增三件事。

第一是交换能力。CXL 交换机可以让一个主机连多个设备，也可以让多个主机共享一组设备。拓扑从点对点变成树形，随之而来的是路由、分区、QoS 这些网络化的概念。

第二是内存池化。多个设备或设备上的多个区域可以组织成一个池，主机按需分配其中的一部分。这个能力对大集群的资源利用率提升很直接——原来每台机器都得按峰值配内存，现在可以按需从池里切。

第三是热插拔和带外管理。设备可以在线加入和移除，配合管理控制器做生命周期管理。这一条对企业级部署是刚需，没有它运维成本会很高。

2.0 还引入了更省带宽的 256 字节 flit 可选模式。早期的 flit 是 68 字节，头部开销占比偏高，256 字节 flit 把有效载荷比例提上来，对大块顺序访问的带宽提升明显。

3.3 3.0：Fabric 与内存共享

3.0 基于 PCIe 6.0 的物理层，引入了 PAM4 编码和 FLIT 模式，单通道速率翻倍。但真正改变玩法的是Fabric 能力：支持更多层级、更大规模的交换网络，支持基于端口的路由，让 CXL 从“机箱内互连”走向“机架级互连”。

另一个重点是内存共享。2.0 的池化是“切块分配”，一块内存同一时刻只归一个主机用。3.0 允许同一块内存被多个主机同时访问，一致性由硬件维护。这对需要共享数据结构的场景——比如多节点共同处理一张大图、多实例共享一份只读特征库——意义很大，因为它省掉了复制和同步。

不过要提醒一句：3.0 的能力很吸引人，但落地节奏受限于芯片、交换机、固件和操作系统的支持成熟度。我在实际项目里选型时，通常会把“规范支持”和“能稳定跑起来”分开看，前者看文档，后者看固件版本和内核版本。

3.4 版本对照速查

这张表我一般建议对照着看，不要只看版本号高低。很多业务在 2.0 的能力范围内就能拿到八成收益，硬上 3.0 反而会因为生态不成熟给自己找麻烦。

4. 在 Linux 上把 CXL 设备跑起来

4.1 硬件和固件的前置检查

这一步最容易被跳过，但它决定了后面 80% 的问题会不会发生。

先看物理链路。设备插在支持 CXL 的插槽上，链路要训练到预期速率和宽度。用lspci -vv看目标设备的 LnkSta 一行，确认速率是 Gen5 或更高、宽度是 x16 或你预期的值。如果链路降速到 Gen1，先别急着怀疑协议兼容性，九成是线缆、重定时器配置或者插槽信号问题。

再看固件。BIOS 里要打开 CXL 相关选项，不同平台的叫法不一样，有的叫 CXL Enable，有的在 PCIe 子菜单里叫 CXL/CCIX Support，还有的把内存解码窗口单独列出来。打开之后，系统启动时才可能生成 ACPI 里的 CXL 发现表。

验证方法是看 ACPI 表。用acpidump -b把表导出来，再用iasl -d反编译，找CEDT（CXL Early Discovery Table）。这张表里有两个关键结构：一个是主机桥结构，描述 CXL 主机桥的寄存器基址；另一个是固定内存窗口结构，描述 CXL 内存可以映射到系统地址空间的哪些窗口。这张表缺失，操作系统就完全不知道有 CXL 这回事，后面所有操作都无从谈起。

# 导出并反编译 ACPI 表，确认 CEDT 是否存在 sudo acpidump -b -o acpi.dat iasl -d acpi.dat grep -i cedt *.dsl

提示：有些平台的 CEDT 只有在插槽里真的有设备、且链路训练成功后才会生成。空槽位下看不到表是正常的，别误判成固件不支持。

4.2 内核配置与关键节点

内核侧的 CXL 子系统在 5.12 之后逐步成形，6.x 系列对 Region、池化、错误处理的支持完善了很多。如果你在跑长期支持版本，先确认内核版本够新，否则cxl命令行工具会提示一堆不支持的操作。

配置上要打开几个开关：CXL 总线与端口驱动、CXL 内存设备与 Region 驱动，如果要把它当普通内存用，还要带上 DAX 和 kmem 相关的选项。这些在主流发行版的默认内核里通常是模块形式，需要确认模块能正常加载。

加载后，设备会出现在/sys/bus/cxl/devices/下面。这个目录的组织方式值得花几分钟理解：root0是根端口，port1之类是下游端口，mem0是内存设备，region0是组装出来的内存区域。它们之间靠符号链接串起来，顺着链接看一遍，拓扑关系就清楚了。

# 看 CXL 设备拓扑 ls -l /sys/bus/cxl/devices/ # 看某个内存设备的容量和健康信息 cat /sys/bus/cxl/devices/mem0/size cat /sys/bus/cxl/devices/mem0/ram/size

size是设备上报的总容量，ram/size是可作为易失内存使用的部分。有些设备会划分出一部分做持久内存，两个值就不一样。这一步的数字对不上，说明设备侧的分区配置和你的预期不一致，需要回去看设备管理工具。

4.3 用 cxl-cli 走一遍从枚举到上线

命令行工具cxl来自 cxl-cli 包，是日常操作的主力。整个流程分四步：发现设备、创建 Region、提交 Region、映射成可用内存。

第一步，看设备在不在。

cxl list -M cxl list -u

-M列内存设备，-u列端口。输出里会显示每个设备属于哪个端口、容量多少、当前有没有被划进某个 Region。

第二步，创建 Region。Region 是把一个或多个内存设备的部分容量组织成一段连续地址空间的操作。单设备场景比较简单，指定解码器和目标设备即可。

cxl create-region -d decoder0.0 -m mem0 -s 64G

这里-d指定根解码器，-m指定内存设备，-s指定大小。多设备交织的场景要指定多个设备和交织粒度，粒度选 256 字节还是 4KB 要看你的访问模式：小粒度交织能让带宽更均匀地摊到多个设备上，但会增加单个请求的拆分开销；大粒度交织对顺序大块访问更友好。

第三步，提交 Region。创建出来的 Region 处于未提交状态，此时还没有真正占用系统地址空间。

cxl enable-region region0

第四步，把 Region 映射成可用内存。有两种常见用法：映射成 DAX 设备，按字节寻址访问，适合自己管理内存的应用；或者交给 kmem 驱动，让它作为一个 NUMA 节点出现在系统里，普通进程用 malloc 就能分配到。

# 方式一：device-dax cxl create-dax -r region0 -t devdax # 方式二：kmem，挂成 NUMA 节点 cxl create-dax -r region0 -t kmem

用 kmem 之后，numactl -H会多出一个节点，/sys/devices/system/node/nodeN/下能看到它的距离值。这时候用numactl --membind=N就能把进程的内存绑到这块远端内存上，做性能对比很方便。

4.4 上线之后怎么确认真的在用

设备挂上了不代表应用在用。我一般做三层验证。

第一层，看 NUMA 拓扑。numactl -H里新节点的距离值是多少，这个数字直接影响调度器的决策。距离值通常由固件根据延迟信息填进 HMAT 表，如果固件没填好，内核可能给出一个不合理的小值，导致调度器误以为它跟本地内存一样快，把热数据全放上去，性能反而崩。

第二层，看实际分配。用numastat观察目标节点的分配量和命中量，或者跑一个绑定内存的微基准，确认分配确实落在远端节点上，而不是回落到本地。

numactl --membind=2 --cpunodebind=0 ./membench --size 8G --stride 64

第三层，看带宽和延迟数字是否落在预期区间。这一步下面单独说。

注意：Region 创建后如果系统重启，配置不一定持久保留。生产环境要把创建流程写进启动脚本或管理工具里，并且在设备固件升级后重新验证一遍地址窗口有没有变化。

5. 性能账：到底快不快、什么时候值得用

5.1 延迟和带宽的量级

先给结论：CXL 内存的延迟比本地 DDR 高，但高得有限；带宽受限于 PCIe 链路，x16 Gen5 双向理论带宽在 60 GB/s 出头这个量级，实际有效带宽要打折。

具体数字上，本地 DDR5 的加载延迟大致在 80 到 100 纳秒。CXL 内存的加载延迟，实测通常在 170 到 250 纳秒之间，具体取决于链路里有没有重定时器、有没有经过交换机、设备侧内存控制器和介质类型。中间每多一级重定时器或者交换机，就要多几十纳秒。这个数字对比网络路径的微秒级，还是快了一个数量级以上，所以对“放不下本地内存又要频繁访问”的数据，它是有价值的；但对比本地内存翻了将近一倍，对延迟敏感的指针追逐型负载就要谨慎。

带宽方面，x16 Gen5 链路的单向理论峰值大约 63 GB/s，扣掉协议开销和实际访问模式的效率损失，顺序读能跑到四五十 GB/s 就算不错了。注意这是链路带宽，和本地 DDR 的每通道几十 GB/s 是不同维度的概念：本地内存是多通道并行，CXL 是一条链路上的串行带宽，所以总量上差距明显。这也解释了为什么 CXL 更适合扩容而不是替代——容量可以靠它扩，带宽不能指望它顶。

5.2 应用侧怎么吃这块内存

内存挂上去之后，怎么用才是决定收益的关键。我总结了几种典型吃法。

第一种是冷热分层。把热数据放本地 DDR，冷数据放 CXL 内存，靠操作系统的 NUMA 平衡或者应用自己的分层逻辑做迁移。这类用法对延迟不敏感，收益直接体现在“原来放不下要落盘的数据现在能放在内存层”。数据库的缓冲池扩展、对象缓存的溢出层都属于这一类。

第二种是容量型负载。内存数据库、图计算、基因组装、大规模特征工程这类负载，特征是“数据集必须全在内存里，但访问分布不均匀”。放到 CXL 内存上，整体延迟上升，但因为避免了换页和磁盘 IO，端到端时间往往是下降的。这一类的收益要靠端到端指标来评估，别只盯着单次访问延迟。

第三种是池化共享。多台机器从同一个池里按需切内存，提高整体利用率。这一类的收益在资源层面而不是单机性能层面，适合弹性伸缩的业务。

第四种是加速器的本地内存扩展。Type 2 设备上挂大块内存，主机直接访问，省掉显式拷贝。这一类对软件改动要求最高，收益也最依赖具体算法。

我的经验是，先做第一种和第二种，改动小、收益明确；池化涉及调度和运维体系，适合规模上去之后再做；第四种要等具体业务真有痛点再投入。

6. 踩坑记录与排查速查表

6.1 设备压根看不到

这是最常见的第一道坎。现象是lspci里能看到设备，但/sys/bus/cxl/devices/下空空如也。

排查顺序我固定为四步。第一，确认lspci里设备的类别和厂商 ID 是否被识别成 CXL 类型，如果只是普通 PCIe 设备，说明固件没把它枚举成 CXL，回去查 BIOS 开关。第二，确认 ACPI 里有 CEDT，缺这张表内核不会创建 CXL 根端口。第三，确认内核版本和模块加载，dmesg | grep -i cxl里应该有主机桥注册的日志。第四，确认链路速率和宽度没降级，降级到 Gen1 时有些平台会直接放弃 CXL 初始化。

还有一种隐蔽情况：设备在，CEDT 也在，但根端口的寄存器基址映射冲突，内核报资源忙。这种要看dmesg里的地址冲突信息，通常是固件留的解码窗口和其他设备重叠，需要调整 BIOS 里的窗口分配。

6.2 Region 建不起来

cxl create-region报错的种类很多，我归纳成三类原因。

一类是容量对不上。设备的可用容量必须按解码器的交织粒度对齐，你要 64G 但设备可用空间是 63.5G，就会失败。cxl list -M里有每个设备的可用容量，先看这个数，别凭标称容量拍脑袋。

二类是解码器状态不对。解码器可能已经被别的 Region 占用，或者处于未使能状态。cxl list -D能看到解码器的当前状态和所属 Region，先清理再重建。

三类是地址窗口不够。主机桥的固定内存窗口大小是固件分配的，你要的容量超过窗口上限就建不起来。这时候要么缩小容量，要么回去改固件的窗口配置。这一条我在早期版本上踩过，结论是“创建 Region 之前先确认窗口余量”，比事后猜错因省事得多。

6.3 挂上了但性能不对

现象是内存能用，但带宽只有预期的三分之一，或者延迟高得离谱。

先查交织配置。单设备无交织是最简单也最快的，多设备小粒度交织虽然摊平了带宽，但每个请求都要跨设备拆分，实际吞吐反而不如预期。我一般先用单设备跑基线，再逐步加交织，每步都测。

再查 NUMA 距离和调度。距离值被固件填得太小，内核会把热页放到远端节点，本地缓存命中率下降，表现为整体变慢但单点测试正常。这种情况用numastat看两边的分配比例就能发现。

最后查链路。重定时器固件版本不匹配、线缆接触不良、交换机端口协商速率不对，都会让实际带宽腰斩。lspci -vv里的链路状态和错误计数是必看的，Correctable Error 持续增长基本就说明物理层有问题。

提示：遇到疑难问题时，先降复杂度。把交换机去掉、把交织关掉、把设备减到一个，跑通最小可用组合，再逐步加回。CXL 的问题绝大多数出在“多了一层”，而不是协议本身。

7. 我这几年攒下的几条实操建议

第一，先确认固件，再动操作系统。CXL 的绝大部分配置在固件层，操作系统只是消费方。我见过太多时间花在内核参数上调来调去，最后发现是 BIOS 里一个开关没开。养成习惯：动手之前先把 CEDT 导出来看一眼，这一分钟能省几小时。

第二，把 NUMA 距离当成一等公民。远端内存能不能用好，很大程度取决于调度器怎么看待它。固件给的延迟信息不准，后面所有优化都是错的。上线前用微基准实测一遍延迟，和numactl -H里的距离值对一对，不一致就去找固件厂商。

第三，别指望 CXL 提升带宽。它的定位是扩容量、提灵活性、降 TCO，带宽受限于链路，永远比不过本地多通道内存。如果你的瓶颈是带宽而不是容量，先想别的办法。

第四，版本匹配比版本高低重要。设备固件、主机固件、内核版本、命令行工具版本，这四者要匹配。我遇到过工具版本比内核新，创建 Region 时参数被静默忽略的情况，排查了半天才发现是工具和内核的接口不一致。固定一套验证过的版本组合，比追新稳妥。

第五，给池化和共享留出评估期。这两个能力听起来很美，但涉及调度、隔离、故障域、计费一整套体系，不是插上就能用。我的做法是先在小规模环境里跑通，把运维流程和监控指标建起来，再考虑铺开。

第六，监控要提前埋。CXL 设备的错误上报走标准的 RAS 通道，Correctable 和 Uncorrectable 错误都要监控。内存这种部件，出问题往往是渐进的，错误计数缓慢增长的时候不处理，等到不可纠正错误就是整机宕。这一条我在项目里吃过亏，后来所有 CXL 节点都加了错误计数告警，阈值设得很低。

这套东西往后还会继续演进，尤其是内存共享和 Fabric 组网这两块，生态成熟之后用法会变。但从现在能落地的部分看，把 Type 3 内存扩展用稳、把 NUMA 策略配对、把错误监控做全，已经能解决相当一部分内存容量和资源利用率的问题了。