第3章:CXL 与硬件互联演进 —— 从 1.1 到 3.0 的三阶段跃迁

CXL(Compute Express Link)是 PCIe 物理层加上一套缓存一致协议,把”远端内存”从 µs 级 RDMA 压回 百 ns 级硬件一致内存。本章梳理 CXL 三代演化(1.1 同机扩展 → 2.0 机柜内 pooling → 3.0 多机柜 sharing)、三类设备(Type 1/2/3),通过 Pond / TPP 这些云端实证理解 CXL 在现实中的能力边界。读完这章你会知道为什么 CXL 不会替代 RDMA,以及”CXL pool 上跑 RDMA”这个研究 frontier 在解什么问题。

📑 目录

• 1. 为什么需要 CXL:PCIe 之上的一层语义
• 2. CXL.io / CXL.cache / CXL.mem:三类协议子集
• 3. Bias 模式:Host bias / Device bias 的实际影响
• 4. Type 1 / Type 2 / Type 3 设备:加速器、SmartNIC、内存扩展器
• 5. CXL 三代演化:同机 → 机柜内 → 多机柜
• 6. Pooling vs Sharing:多主机访问同一段内存的两种姿势
• 7. 延迟数字真相:CXL 实测 vs 宣传
• 8. 工业实证:Pond 深度解读
• 9. TPP:Meta 透明 page placement
• 10. 软件栈:Linux DAX / ndctl / daxctl
• 11. CXL vs RDMA:不是替代,是两条平行通路
• 12. 失败模式与生态成熟度
• 自我检验清单
• 参考资料

---

1. 为什么需要 CXL:PCIe 之上的一层语义

PCIe 5.0 单 lane 32 GT/s,x16 双向 128 GB/s——带宽够用。但 PCIe 有一个根本问题:没有缓存一致语义。

设备访问 host 内存只能走 DMA(批量、显式、应用层维护一致性),host 访问设备内存要走 MMIO(慢、不进 cache)。这种”软件管一致性”在 GPU 训练这种粗粒度数据流上没问题,但在细粒度高频共享(比如 hash 表、共享队列)上代价巨大——每次访问都要显式 flush / invalidate cache,单次操作开销比访问本身还高。

CXL 的核心创新是在 PCIe 5.0 物理层之上,加了一套 cache-coherent 协议——让 CPU 和加速器能像访问本地 DRAM 一样访问设备内存,hardware 自动维护 cache line 一致性。

       软件一致(MPI / RDMA)         硬件一致(CXL)
       ─────────────────────       ─────────────────────
       app 显式 send/recv            CPU load/store 自动
       libibverbs 调度               MMU + coherence engine
       TLB miss 自处理               硬件维护 directory
       延迟 ~µs                     延迟 ~100-300 ns
       容量任意                     物理上限(几 TB / pool)
       跨数据中心可扩展             机柜内或机柜间(< 100m)

🌟 结论:CXL 不是”更快的 RDMA”,而是”硬件一致的远端访问”。它把”远端内存”从消息传递语义压回 load/store 语义,代价是物理距离严格受限(电信号 + 一致性同步窗口)。

🍎 直觉比喻:RDMA 是”快递寄包裹”,CXL 是”开个对外门”。寄包裹可以跨城市,但每次都要打包+签收;开门可以走两步进去拿,但只能在邻居范围内。

维度	PCIe DMA(传统)	CXL
一致性	软件维护(刷 cache、屏障)	硬件维护
CPU 视角访问设备内存	MMIO(uncached)	load/store(cached)
设备视角访问 host 内存	DMA(批量)	load/store + cache
编程复杂度	高	低(像 NUMA)
单次访问粒度	大块(KB-MB)	cache-line(64B)

⭕ 历史背景:CXL 诞生前,Intel 推过 OmniPath、IBM 有 OpenCAPI、AMD 有 Infinity Fabric——都是”PCIe + 一致性”的尝试,但生态分裂。CXL 在 2019 由 Intel 主导发起,后大部分厂商加入 CXL Consortium(包括 AMD、ARM、NVIDIA、Microsoft),迅速统一标准。OpenCAPI / Gen-Z 等竞争者基本退场,CXL 成事实标准。

2. CXL.io / CXL.cache / CXL.mem:三类协议子集

CXL 1.1 定义了三个并行的子协议,在同一根 PCIe 5.0 物理链路上以 flit-based 方式复用:

• CXL.io:基本上等同 PCIe(配置、DMA、中断),向后兼容 PCIe 设备
• CXL.cache:设备可以缓存 host 的内存,host CPU 看到的是一致 cache line。设备 cache miss 时走 CXL.cache 协议向 host 申请数据
• CXL.mem:host 可以访问设备暴露的内存,设备成为 host 内存空间的一部分(NUMA-like)

                        Host CPU
                     ┌─────────────┐
                     │  L1/L2/L3   │
                     │  cache      │
                     └──────┬──────┘
                            │ coherence
                            ▼
              ┌─────────────────────────────┐
              │       CXL Root Complex      │
              └────┬─────────┬──────────┬───┘
                   │         │          │
              CXL.io    CXL.cache    CXL.mem
                   │         │          │
              ┌────▼────┐    │     ┌────▼────┐
              │ Type 3  │    │     │ Type 3  │
              │ (mem    │    │     │ (mem    │
              │  exp)   │    │     │  pool)  │
              └─────────┘    │     └─────────┘
                       ┌─────▼─────┐
                       │  Type 1/2  │
                       │ (accel)    │
                       └────────────┘

2.1 CXL.io:兼容性基础

承担配置 + DMA + 中断,几乎等同 PCIe TLP(Transaction Layer Packet)。所有 CXL 设备都必须支持 CXL.io,因为 enumeration、配置 BAR、interrupt 路由都走它。

把它看作”CXL 设备的引导通道”,运行时也能 fallback 到纯 PCIe DMA。

2.2 CXL.cache:设备视角拉 host 内存

设备需要细粒度访问 host 内存时,走 CXL.cache:

设备内 cache miss
     │
     │  CXL.cache 请求(类似 cache coherence message)
     ▼
Host 内存控制器
     │  返回 cache line(64B), 标记此 line 在某设备 cache 中
     ▼
设备 cache fill

Host 做了写动作时,要 invalidate 设备 cache(snoop)。整个协议类似 ccNUMA 跨 socket 协议——只是物理通路是 CXL 而不是 UPI/Infinity Fabric。

2.3 CXL.mem:host 视角访问设备内存

设备暴露一段地址,host 把它当作另一个 NUMA node。CPU load addr 时:

• MMU 翻译虚拟地址 → 物理地址(物理地址在 CXL device 暴露的范围内)
• 走 CXL.mem 协议,device 返回 64B cache-line
• CPU L3 cache fill,后续访问 cache 命中

延迟:典型 100-300ns(比本地 DDR 200ns 略慢一点点),但比 PCIe MMIO 快几十倍。

2.4 三协议组合形成设备类型

后面 §4 会展开,但提前预告:

• 只 CXL.io + CXL.cache → Type 1
• CXL.io + CXL.cache + CXL.mem → Type 2
• 只 CXL.io + CXL.mem → Type 3

3. Bias 模式:Host bias / Device bias 的实际影响

CXL.cache 引入了一个细节:数据”主要在哪一侧 cache”——bias 模式。

3.1 Host bias

数据主要被 CPU 访问,设备偶尔访问。机制:

• 数据驻留 host cache
• 设备访问时,通过 CXL.cache 拉回设备本地 cache(snoop host)
• 性能特征:CPU 访问最快,设备访问慢(每次跨 link)

3.2 Device bias

数据主要被设备访问,CPU 偶尔访问。机制:

• 数据驻留设备本地 cache
• CPU 访问时,通过 CXL.cache 从设备 cache 拉回(snoop device)
• 性能特征:设备访问最快,CPU 访问慢

3.3 Bias 切换

应用可以通过 cxl-cli 或编程接口切换 bias:

// 伪代码: 切到 device bias
cxl_set_bias(addr, len, CXL_BIAS_DEVICE);
// 此后该地址段:设备访问快,CPU 访问慢

Bias 切换不是免费的——要 flush 双方 cache、更新 directory。生产中避免频繁切换。

3.4 实际选择

场景	推荐 bias
GPU 跑长时间 kernel,CPU 偶尔检查	Device bias
CPU 准备数据 → 给 GPU 处理 → 拿回结果	Host → Device → Host(bias 切换贵,通常宁可用 zero-copy 复制方案)
共享队列(双方频繁访问)	不适合 CXL.cache,用 CXL.mem + 软件协议更好

⚠️ 关键陷阱:Bias 切换频繁的场景反而比纯 PCIe DMA 慢。CXL.cache 适合”长时间一侧主导”的访问模式,频繁双向交互不是它的菜。

4. Type 1 / Type 2 / Type 3 设备:加速器、SmartNIC、内存扩展器

按能力划分,CXL 设备有三类:

类型	协议组合	含义	典型产品	主要场景
Type 1	CXL.io + CXL.cache	设备能 cache host 内存,但自身没暴露内存	SmartNIC、加密卡、网络处理器	加速器需要”细粒度”读 host 数据
Type 2	CXL.io + CXL.cache + CXL.mem	既能 cache host,自身又有内存暴露给 host	GPU、ML 加速器、FPGA	GPU+CXL 一致内存共享
Type 3	CXL.io + CXL.mem	设备只暴露内存(纯 memory expander)	Astera Labs、Samsung、Micron CXL 卡	服务器 DDR 扩展 / memory pool

4.1 Type 1:加速器视角拉 host 数据

Type 1 设备没有”暴露给 host 的内存”,只是自己有缓存,需要 cache-coherent 拉 host 数据。

典型:SmartNIC(Bluefield-3)、加密/压缩卡、网络处理器。这些设备处理数据时,数据在 host 内存,设备通过 CXL.cache 细粒度拉取(而不是 DMA 大块复制)。

收益:对短查询、随机访问、小消息特别有效——以前要 DMA 复制整段,现在按需 64B 拉取。

4.2 Type 2:GPU + CXL 共享内存

Type 2 是最复杂的——既 cache host,又暴露设备本地 HBM/DRAM 给 host。理想场景:

• CPU 准备数据放 host 内存
• GPU 通过 CXL.cache 直接读 host(无需 DMA)
• GPU 处理完写到自己 HBM,host 通过 CXL.mem 一致地访问 GPU HBM

现实:2026 年 GPU 域 CXL 仍未真正落地——NVIDIA 的 NVLink + Grace Hopper 已经覆盖主要场景,Intel/AMD 的 Type 2 GPU 处于早期。

⭕ CXL 在 GPU 域的”势”:Intel / AMD 在 GPU(MI300、Falcon Shores)上推 CXL Type 2,主推CPU+GPU 异构计算(MI300 同 die 集成 CPU+GPU + CXL 一致内存)。NVIDIA Grace Hopper 用 NVLink-C2C(自家协议,功能类似)。长期看 CXL 可能成为非 NVIDIA 阵营的标准选项。

4.3 Type 3:成熟商业化的代表

Type 3 是当前最成熟、最容易商业化的——本质就是”一根 CXL 卡上插几条 DDR5,让服务器看到额外的 NUMA node”。

形态:

       Server
       ┌──────────────────────┐
       │   CPU                │
       │   ┌────────────┐     │
       │   │ Local DDR  │     │
       │   │ NUMA 0/1   │     │
       │   └────────────┘     │
       │                      │
       │   ┌────────────┐     │
       │   │ CXL Type 3 │ ◄── │ NUMA 2 (CXL pool)
       │   │ Card       │     │ 几百 GB - 1TB
       │   └────────────┘     │
       └──────────────────────┘

生态里 90% 的真实产品和论文实证都是 Type 3:

厂商	产品	容量	协议	状态(2026)
Astera Labs	Leo	256-512 GB	CXL 2.0	量产,主流
Samsung	CXL Memory Expander	128-512 GB	CXL 2.0	量产
Micron	CZ120	128-256 GB	CXL 2.0	工程样品到早期客户
SK hynix	CXL DDR5 module	128 GB	CXL 2.0	量产
Intel	Agilex CXL FPGA	可定制	CXL 1.1/2.0	主要给客户做定制

数据为公开规格的合理估计,具体型号请查厂商最新 datasheet。

5. CXL 三代演化:同机 → 机柜内 → 多机柜

版本	发布	核心新增能力	距离	典型场景
CXL 1.0/1.1	2019	基本三协议 + Type 1/2/3	同机内(直连)	单机内存扩展、加速器一致访问
CXL 2.0	2020	CXL Switch + Memory Pooling + IDE 安全	机柜内(< 5m)	多 host 共享一组 memory expander
CXL 3.0	2022	Fabric + Memory Sharing + 64 GT/s + multi-level switch	多机柜内(< 30m)	大规模 memory fabric + 多 host 真共享
CXL 3.1	2023	安全(IDE 加固)、global FAM、可信计算	同 3.0	加固生产部署

5.1 CXL 1.1:点对点

[Host] ──CXL──► [Type 3 卡]
[Host] ──CXL──► [Type 3 卡]

简单直连,单 host 一对多。基本能力:把额外内存挂上来。

5.2 CXL 2.0:加 switch,引入 pooling

[Host A] ──┐
[Host B] ──┼─► [CXL Switch] ──► [Type 3 cards]
[Host C] ──┘                       (内存模块池)

Switch 让多个 host 共享一组内存模块,但每段内存同一时刻只属于一个 host(类似云盘的 attach/detach)。

关键能力:

• Memory Pooling:host A 闲下来,把它的那段内存”还回池”,host B 可以申请挂载
• Hot-add / hot-remove:OS 看到 NUMA node 动态出现 / 消失
• IDE(Integrity & Data Encryption):数据在 CXL 链路上加密(防止物理探测)

5.3 CXL 3.0:真 fabric 化

              [CXL Fabric (multi-level switches)]
              │       │       │       │
         [Host A] [Host B] [Host C] [Host D]
              │       │       │       │
              └───────┴───────┴───────┘
                          │
              [Shared Memory Region]
              (多 host 同时一致访问)

关键能力:

• Memory Sharing:多 host 同时一致访问同一物理段(directory-based coherence)
• Multi-level switching:可以多级 switch 互联,扩展物理规模
• 64 GT/s:物理层带宽翻倍(2.0 是 32 GT/s)
• Fabric Manager:有专门的管理实体协调多 host

🧠 关键洞察:CXL 3.0 的 “real sharing” 把分布式系统的核心难题重新定义了——以往多主机共享内存要靠软件协议(比如 ccNUMA 跨 socket、或 RDMA 上的软件协议),现在硬件自己做。但软件假设(锁、内存模型、failure domain)还没跟上,这是当前主要研究方向。

5.4 CXL 3.1 的小改进

主要是安全加固:IDE 协议增强、可信计算扩展、global Fabric Attached Memory(FAM)定义更清晰。功能上没大跃迁,3.1 就是 3.0 的 production-ready 版。

6. Pooling vs Sharing:多主机访问同一段内存的两种姿势

容易混淆的两个概念,本质完全不同。

6.1 Pooling(2.0 引入)

多个 host 共享一组内存”硬件池”,但每段地址同一时刻只 attach 到一个 host。类似云盘——盘是公共的,但每个盘只挂在一台机器上,可以重新挂载。

       Host A    Host B    Host C
         │         │         │
         └─────┬───┴───┬─────┘
               │       │       (CXL Switch)
       ┌───────┴───────┴────────┐
       │  Memory Expander Pool   │
       │  ┌─────┬─────┬─────┐    │
       │  │ A的 │ B的 │ C的 │    │ ← 每段只属于一个 host
       │  └─────┴─────┴─────┘    │
       └─────────────────────────┘

关键属性:

• 每段内存 exclusive attach 到某 host
• Host 之间不共享 cache line(无一致性问题)
• 调度器决定”哪段给谁”——可以基于负载、租户优先级
• Re-attach 需要 OS 配合(unmount → attach to new host → mount)

适合场景:资源弹性(B 闲下来后,A 可以”借” B 之前那段)。Pond(微软)的核心收益就是这个。

不适合场景:多 host 同时读写同一数据(必须用 sharing)。

6.2 Sharing(3.0 引入)

多个 host 同时一致访问同一物理段,硬件维护 cache 一致性。

       Host A    Host B    Host C
         │         │         │
         └─────┬───┴───┬─────┘   (CXL Fabric, 一致性域)
       ┌───────┴───────┴────────┐
       │  Shared Memory Region   │ ← 三个 host 同时读写
       │  (硬件 directory 维护一致)│
       └─────────────────────────┘

关键属性:

• Host 之间强 cache coherent(硬件 directory 维护)
• 多 host load/store 同一地址 → 硬件保证看到一致状态
• Memory ordering 保证(类似单机 ccNUMA)
• Failure domain 跨 host

适合场景:真共享数据(分布式 hash 表、shared queue、共识协议加速)。但软件挑战巨大:

• 共享内存上的并发数据结构需要重新审视(锁的语义、ABA 问题、内存序)
• failure domain 跨 host(一个 host crash 时其他 host 看到的状态机变了)
• 多租户隔离(没法只给 host A 一段,因为 directory 是物理整体)
• Page fault 跨 host 协调

6.3 两者比较

维度	Pooling(2.0)	Sharing(3.0)
同一时刻 attach 多 host	❌	✅
一致性	N/A(独占)	硬件强一致
软件改动	小(像 hot-plug NUMA)	大(分布式编程模型重写)
故障域	单 host	多 host(必须协调)
商业化时间	已落地(2024+)	3-5 年(2027+)
主要应用	VM 弹性内存、TCO 优化	分布式数据结构、共识加速

🌟 结论:短期(3-5 年)主流是 pooling,因为它只重写底层 OS;sharing 要重写整套分布式编程模型,2026 年仍是科研课题。

7. 延迟数字真相:CXL 实测 vs 宣传

CXL 厂商喜欢说”100ns 延迟”,但实测往往不止。需要拆开看:

7.1 延迟构成

Total CXL.mem load latency = 
    L1/L2/L3 cache lookup miss      ~5-20 ns
  + CXL link 传输                    ~30-80 ns
  + Type 3 设备内 DDR access         ~30-80 ns
  + 返回 cache fill                  ~20-30 ns
  ─────────────────────────────────
  Total                              ~100-200 ns

vs 本地 DDR:本地 DDR 一次 load(L3 miss)~80-100 ns。CXL 比本地慢 1.5-2.5×,不是”100ns 完全等同”。

7.2 实测数字(社区测试,2024-2025)

平台	测试场景	延迟
Intel SPR + Astera Labs Leo	顺序 load(64B)	~150 ns
同上	随机 load(prefetch 不命中)	~200-300 ns
同上	NUMA local DDR(对照)	~80-100 ns
同上	NUMA remote(socket-1)	~120-150 ns

带宽:CXL 2.0 x16 单方向 ~32 GB/s(理论),实测 ~25-30 GB/s。本地 DDR5 一通道 ~50 GB/s,8 通道 ~400 GB/s。CXL 的带宽通常比本地 DDR 总和低。

7.3 与 RDMA 数字对比

通路	延迟	带宽
Local DDR	80-100 ns	400+ GB/s(8 channel)
CXL.mem(Type 3 同机)	150-300 ns	25-30 GB/s(x16 单根)
RDMA 100GbE one-sided READ(同 LAN)	1-3 µs	12 GB/s(单根)
RDMA 200GbE	0.8-2 µs	25 GB/s

CXL 比 RDMA 快 5-20×,比本地 DDR 慢 1.5-3×——这是它的物理位置。

⚠️ 错误认知:“CXL 等于本地 DDR”——错。CXL 是新的 NUMA 远端,延迟比 socket-remote DDR 略高。系统设计时要把它当作”另一层 NUMA”,不能假装无差别。

8. 工业实证:Pond 深度解读

Pond(Microsoft, ASPLOS’23)是 CXL Type 3 在生产数据中心的最系统实证。

8.1 问题陈述

Azure 数据中心一台服务器配置:2× CPU + 1.5 TB DDR5。但 VM 实际申请的内存大头是 8GB-32GB。问题:

• 大量”零碎”VM 拼起来,整台机内存利用率仍只 60-70%
• 单个 VM 的内存访问大部分集中在少数热页面(80/20 分布)
• 大量”冷页面”(几乎不访问)被本地 DDR 占用 → 浪费

8.2 ZNUMA 设计

Z(zero-?)NUMA:把 CXL Type 3 卡当作”额外的 NUMA node”,但调度器知道它慢一点,所以做差异化分配。

       VM 申请内存
            │
            │ scheduler 决策
            ▼
   ┌────────────────────────────────────┐
   │ 80% 热页 → 本地 DDR (NUMA 0/1)      │
   │ 20% 冷页 → CXL pool (NUMA 2)        │
   └────────────────────────────────────┘

关键工程:

• Page hotness 预测:用 PMU 统计 page 访问频率,识别”冷页面”
• Migration 触发:周期性把冷的本地页迁去 CXL pool(后台异步)
• VM 透明:VM 看到的还是统一内存,kernel 在底下做 placement
• 保险:hot page 永远在本地;只有 confirmed cold 才迁

8.3 关键数据(论文公开)

• VM workloads 中约 50% 的内存访问对延迟不敏感(冷数据、批处理)
• 把这部分内存放到 CXL pool 上,TCO 节省 7-9%
• 对延迟敏感 VM(数据库、推理),性能影响 <1%
• 数据中心规模:Azure 现已部分部署

8.4 关键洞察

🌟 Pond 的真正贡献不是”CXL 牛逼”,而是:

• 用真实云端数据证明”延迟松一些的内存”是普遍存在的(50% 比例)
• 给数据中心一个 7-9% TCO 节省的具体账本
• 证明 NUMA-style placement 可以把 CXL 集成到现有 OS / VM 框架,不需要重写应用

这是 disaggregated memory 在数据中心可以商业化的核心 evidence——不是性能 demo,是经济账。

9. TPP:Meta 透明 page placement

TPP(Transparent Page Placement,Meta, ASPLOS’23)与 Pond 同期发表,视角更底层:不是 VM 调度,而是 kernel 层的页面 hotness 跟踪 + 自动迁移。

9.1 核心机制

       Meta server
       ┌─────────────────────────┐
       │  Linux kernel           │
       │   ┌─────────────────┐   │
       │   │ Page tracker    │   │ 用 PMU 跟踪 page access
       │   │ (PEBS/IBS)      │   │
       │   └────────┬────────┘   │
       │            ▼            │
       │   ┌─────────────────┐   │
       │   │ Migration daemon│   │ hot → local, cold → CXL
       │   └─────────────────┘   │
       │                         │
       │  Local DDR    CXL Type 3│
       │  (hot pages)  (cold)    │
       └─────────────────────────┘

9.2 vs Linux NUMA balancing

Linux 原生有 numa balancing(基于 access fault),但:

• 假设所有 NUMA node 性能相当 → CXL 比 local 慢,假设不成立
• 不能区分”冷热程度”(只看是否被访问,不看频率)
• 反应慢(几秒级别)

TPP 改进:

• 基于硬件 PMU 计数(更准、更快)
• 冷热分级(不止 “yes/no”,有温度梯度)
• 更激进的 promote / demote 策略(更快迁移)

9.3 数据中心实证

• 在 Meta production server 上跑了几个月
• 关键 workload(社交图谱、ML 推理)延迟影响 <2%
• CXL 内存利用率 30-40%(配合 VM 调度可以更高)

⭐ Pond + TPP 这两篇 ASPLOS’23 同期论文,基本奠定了 CXL Type 3 在大规模数据中心的可行性证据。一个从 VM 调度切入(微软),一个从 kernel placement 切入(Meta),殊途同归。

9.4 与 Linux 主线的演化

TPP 部分 idea 已合入 Linux 主线(mempolicy 扩展、MEMPOLICY_PREFERRED_MANY 等),但核心 hotness tracking 和 migration daemon 仍需 Meta 自己维护(production patch 大约几千行)。

社区版本逐步追上,预计 2026-2027 Linux 主线 NUMA balancing 会全面 CXL-aware。

10. 软件栈:Linux DAX / ndctl / daxctl

CXL 在软件层不是”装个驱动就完”,涉及一整套工具链。

10.1 设备发现

# 看 CXL 设备
cxl list

# 输出示例(简化):
# [
#   {
#     "memdev":"mem0",
#     "pmem_size":"512.00 GiB",
#     "ram_size":"512.00 GiB",
#     "host":"0000:65:00.0"
#   }
# ]

# 详细信息
cxl list -m -d mem0

10.2 配置为可访问的内存

CXL 设备出厂后通常处于 “raw” 状态,要配置成 system-ram 或 dax:

# 模式 1: System RAM (作为 NUMA node 给所有应用)
sudo daxctl reconfigure-device --mode=system-ram /dev/dax0.0
# 之后 numactl --hardware 应该看到新 node

# 模式 2: DAX(只给特殊应用)
sudo daxctl reconfigure-device --mode=devdax /dev/dax0.0
# 应用通过 mmap /dev/dax0.0 显式访问

10.3 在应用中使用

System RAM 模式:

# 看 NUMA topology
numactl --hardware

# 强制让某进程优先用 CXL node(假设是 NUMA 2)
numactl --membind=2 ./my_app
# 或 preferred(优先但允许 fallback)
numactl --preferred=2 ./my_app

DAX 模式(显式 mmap):

int fd = open("/dev/dax0.0", O_RDWR);
void *mem = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 直接 load/store 到 mem,硬件一致

10.4 Hot-add / Hot-remove

CXL 2.0+ 支持热插拔——新挂一根 CXL 卡时,OS 看到新 NUMA node 出现:

# 触发 device probe
echo 1 > /sys/bus/cxl/devices/.../probe

# 看新 node
numactl --hardware

⚠️ 生产中 hot-remove 是难点——必须先把该 node 上所有页迁出,否则进程崩。社区在做 graceful unbind 流程,2026 年仍非完全自动化。

11. CXL vs RDMA:不是替代,是两条平行通路

新人最常见的误区:“CXL 出来后 RDMA 就没用了”。实际不会发生——它们解的是不同尺度的问题。

11.1 详细对比

维度	CXL	RDMA
物理距离	< 30m(机柜内 / 跨机柜)	数据中心 / 跨 region
延迟	100-300 ns	1-3 µs(同 LAN)
一致性	硬件 cache-coherent	软件维护
编程模型	load/store(透明)	verbs(显式)
容量上限	几 TB(物理 fabric 受限)	几乎无限(网络可扩展)
失败域	同机柜域	跨机房
多租户隔离	弱(directory 物理共享)	强(QP、PD 隔离)
成熟度(2026)	Type 3 量产、3.0 早期	极成熟
单卡价格	$1500-$3000(估算)	$1000-$2000(ConnectX-6/7)

11.2 长期共存格局

• CXL 解决”机柜内热数据”(显式数据库 buffer、热 KV-cache、训练 activation)
• RDMA 解决”跨机柜冷数据 / 远端协调”(DM 事务的 MN、跨 region 复制、collective communication)

🧠 frontier 方向:“CXL pool 上跑 RDMA 协议”——用 RDMA verbs 接口跨机柜访问的对象实际后端是 CXL pool,这样:

• 应用接口保持 RDMA 语义(已有大量代码)
• 同机柜内享受 CXL 低延迟
• 跨机柜降级为 RDMA over CXL fabric 网关

这是 2025-2026 学术 frontier 之一,但商业落地还需 CXL 3.0 fabric 普及(预计 2027+)。

11.3 两者结合的实际场景

场景	CXL 角色	RDMA 角色
Disaggregated DB	同机柜内热 buffer(CXL pool)	跨机柜协调(RDMA verbs)
LLM serving	节点内 KV cache(CXL Type 3)	跨节点 KV transfer(RDMA + GPUDirect)
AI training	单机内 optimizer offload(CXL)	跨节点 allreduce(RDMA NCCL)
共享 hash 表	机柜内一致访问(CXL 3.0 sharing)	跨机柜协调(RDMA)

12. 失败模式与生态成熟度

不要被宣传带偏,CXL 2026 年的现状是”早期成熟”:

12.1 已经成熟的部分

• ✅ Type 3 量产、生态稳定(Astera/Samsung/Micron 多厂商)
• ✅ Linux 主线 CXL.mem 完整支持(kernel 6.x)
• ✅ 工具链(cxl-cli、ndctl、daxctl)可用
• ✅ Pond / TPP 在 hyperscale 已部署

12.2 仍在演化的部分

• ⚠️ CXL 2.0 Pooling 的多 host 协调:fabric manager 实现各家不一,缺标准
• ⚠️ CXL 3.0 Sharing:硬件几乎没量产,软件假设(分布式锁、failure domain)还没框架
• ⚠️ Type 2(GPU)生态:NVIDIA 走 NVLink-C2C,Intel/AMD 走 CXL,割裂
• ⚠️ Hot-remove 工具链:graceful unbind 还没全自动

12.3 失败模式

⚠️ 常见生产事故:

• CXL 卡固件 bug:特定 access pattern 触发 panic(早期产品较多)
• NUMA 调度配错:本应 local 的 hot page 被错放 CXL,延迟突增
• Hot-add 后 bias 配置错:device bias 设到了 host 主导的页 → 性能崩
• 跨厂商兼容性:Switch 与 expander 来自不同厂商时,握手协议有版本兼容问题
• 性能监控盲区:传统 perf / top 不区分 local DDR vs CXL,需要 PMU 专门 metric

12.4 推荐采用节奏

阶段	适合	不适合
2024-2025	Type 3 内存扩容(同机)	多 host 共享
2025-2026	CXL 2.0 pool(VM 弹性)	sharing(3.0 还早)
2026-2027	早期 3.0 fabric 试点	全栈替代 RDMA
2027+	大规模 fabric + sharing	—

🌟 结论:今天用 CXL,首选 Type 3 + NUMA-aware 调度;Type 2 GPU 等 NVIDIA 与 Intel 的路线收敛;Sharing 等到 2027+。

---

✅ 自我检验清单

• CXL 引入价值:能用一句话讲清”为什么 PCIe 5.0 带宽不够,要 CXL”
• 三协议子集:能讲清 .io / .cache / .mem 各自的边界
• Bias 模式:能解释”为什么 bias 切换不能太频繁”
• 三类设备:面对一个新硬件能判断它是 Type 1/2/3
• 三代差异:能默写 1.1 / 2.0 / 3.0 各自最大新增能力
• pooling vs sharing:能讲清两者对 OS / 应用的不同影响
• 延迟真相:能给出 CXL 实测延迟相对本地 DDR 的倍率(1.5-3×)
• Pond 的关键发现:能复述 ZNUMA 的成本收益数字(50% 冷 / 7-9% TCO)
• TPP 与 Linux NUMA balancing 区别:能讲清三点改进
• 软件栈:能用 cxl / daxctl / numactl 完成一次配置流程
• CXL vs RDMA:能在一个具体场景下判断该用哪个
• 生态成熟度:能给出”2026 年用 CXL 推荐先用 Type 3”的理由

---

📚 参考资料

概念入门

• CXL Consortium 官方白皮书:computeexpresslink.org —— 三代演化的权威说明,初学先读
• An Introduction to CXL Memory Pooling —— SemiAnalysis 系列科普
• The Next Platform CXL 系列报道 —— 行业视角综述

关键论文

• Pond: CXL-Based Memory Pooling Systems for Cloud Platforms(Li et al., ASPLOS’23):ACM DL —— 微软 Azure 真实云端实证 ⭐
• TPP: Transparent Page Placement for CXL-Enabled Tiered Memory(Maruf et al., ASPLOS’23):arXiv 2206.02878 —— Meta 数据中心透明 placement ⭐
• Demystifying CXL Memory with Genuine CXL-Ready Systems(Sun et al., ISCA’24) —— 真机性能 microbench
• DirectCXL: Disaggregated Direct Memory Access via CXL(2023) —— 早期 CXL 真机研究
• Memtis: Efficient Memory Tiering with Dynamic Page Classification(Lee et al., SOSP’23) —— TPP 类工作的精进
• An Empirical Guide to the Behavior and Use of Scalable Persistent Memory(Yang et al., FAST’20) —— 与 CXL 概念相邻的 PMEM 实证(对照学习)

行业讨论

• The Next Platform 的 CXL 系列报道
• SemiAnalysis 的 CXL ecosystem 综述
• IEEE Spectrum CXL vs OpenCAPI vs Gen-Z 历史回顾
• OCP(Open Compute Project) memory disaggregation working group 报告

框架文档

• Linux CXL driver(kernel/drivers/cxl) —— Linux 主线 CXL 子系统
• ndctl/cxlctl 工具链:github.com/pmem/ndctl
• DAX(Direct Access)文档:kernel.org docs
• CXL Consortium 发布的 specification(注册即可下载)

下一章我们走进 disaggregated memory 的”传统主战场” —— DM 事务系统。