可拆分 OS：CXL 内存池化如何动摇本地 DRAM 假设

原文发布于 quant67.com，转载请保留出处。

过去三十年，通用 OS 默认：CPU、DRAM、块设备在同一台机器上 ，通过本地 PCIe/NVMe 与内存总线访问。NUMA 内存篇已说明"本地 vs 远端 socket"的延迟差；CXL（Compute Express Link） 与 RDMA 网络把"远端"推到机架级------内存可以插在别的盒子里，仍被本机 CPU 以 load/store 访问。

可拆分 OS（Disaggregated OS） 不是单一产品，而是两类趋势的交汇：

硬件解耦：计算池、内存池、存储池独立扩缩容。
内核重构：学术研究把传统 monolithic OS 拆成通过网络协作的组件（LegoOS、PhantomOS 等）。

本文回答：CXL 改变了哪些内核假设？Linux 已经做了什么？全栈 disaggregated OS 离生产还有多远？

一、资源解耦：从一体机到池化

1.1 传统假设

monolithic OS（Linux、FreeBSD、Windows NT）共享以下隐含前提：

假设	内核中的体现
物理内存统一编址	`struct page`、buddy allocator、伙伴分配器
页错误可从本地或近端 NUMA 满足	`handle_mm_fault`、缺页处理
换出到本地块设备	swap、writeback
设备 DMA 到本地 DRAM	IOMMU 映射

当 慢内存 的延迟从 NUMA 的 ~150ns 上升到 CXL 的 200--400ns+ （因拓扑与代际而异，以厂商规格为准），仍可用同一套页表接口，但 访问模式 必须变------否则应用按"全本地 DRAM"写，性能崩塌。

1.2 解耦动机

数据中心经济学驱动解耦：

内存 stranded：计算密集型节点内存空，内存密集型节点 CPU 空
独立刷新周期：CPU 代际 1--2 年，DRAM 容量需求年增 20%+
故障域：希望单节点故障不拖垮整机架内存

解耦后单台 计算节点 可能只配 足够引导与热数据的 DRAM ，大容量放 CXL 扩展器 或 远程内存服务。

1.3 与虚拟化的关系

容器隔离与 KVM 假设 Guest 物理内存由 Host 分配。CXL 池化后，Host 可能从 机架内存池 划页给 VM------Hypervisor 的内存热插拔、NUMA 伪造、气球驱动（virtio-balloon）都要感知 新拓扑 。下一篇 OS 展望会把 CXL 与机密计算、io_uring 并列为十年趋势。

二、CXL 规范与语义

2.1 三代概览

CXL 基于 PCIe 物理层，协议分三类（CXL Consortium 规范，A 级）：

协议	语义	OS 可见性
CXL.io	配置、发现、中断（类似 PCIe MMIO）	标准 PCIe 枚举
CXL.cache	设备缓存主机内存（加速器一致性）	与设备驱动、coherency 相关
CXL.mem	主机把设备内存当作额外物理地址空间	OS 内存管理核心

本文聚焦 CXL.mem：CPU 对扩展内存发出普通 load/store，硬件负责协议转换。

2.2 CXL 2.0

CXL 2.0 引入 内存扩展器（Memory Expander） 设备类型、HDML（Host-managed Device Memory Linear） 等，使 OS 可将扩展器 DRAM 列为 独立 NUMA 节点 或 System RAM 扩展（实现依赖固件与内核策略）。

关键能力：

单主机挂多个扩展器
热插拔（需 ACPI/CEDT 表配合）
与 PCIe 5.0 带宽绑定

2.3 CXL 3.0

CXL 3.0 向 机架级池化 推进（规范公开资料，A 级）：

多主机共享 同一内存池（需硬件一致性或软件协议）
Back-Invalidation 与广播 snoop 语义增强
Fabric 交换内存与 IO 资源

对 OS 的冲击：从"本机 NUMA"变为 可能跨主机的缓存一致性或软件分布式页管理------这正是 LegoOS 类研究的动机，而非当前主线 Linux 的默认路径。

2.4 延迟与带宽的工程口径

本文不提供自测 benchmark。 厂商与学术文献常见口径：

本地 DDR：~80--100ns 负载延迟（取决于代际与频率）
跨 socket NUMA：~140--200ns（见 NUMA）
CXL.mem：高于本地 NUMA，约 1.5--3× 本地 DRAM 延迟 区间常被引用；带宽受 PCIe/CXL 链路限制

容量规划应使用 node distances 与 实际 lmbench / STREAM 在目标硬件上实测，而非外推。

三、学术原型：LegoOS、PhantomOS、Twilight

3.1 LegoOS（OSDI 2018）

Shan 等 LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation 提出 拆分 monolithic OS：

组件	职责	运行位置
pComponent	进程/线程、调度、系统调用	计算节点
mComponent	物理页分配、页缓存、换出	内存节点
sComponent	文件系统块、持久化	存储节点

进程在 pComponent 执行；访问未映射页触发 分布式缺页 ，mComponent 经 RDMA 传页（论文报告 ~1--10μs 级远程缺页服务延迟，取决于网络与实现）。

sequenceDiagram participant App as 应用 participant p as pComponent participant m as mComponent participant Net as RDMA 网络 App->>p: load 未映射地址 p->>p: 缺页陷阱 p->>Net: 请求页面 Net->>m: RDMA Read m-->>Net: 页面数据 Net-->>p: 完成映射 p-->>App: 继续执行

意义：证明 OS 接口可保持 POSIX 外观，而 页后端 远程化。局限：单点 mComponent 故障、一致性、元数据放大、安全边界------均未达到 Linux 生产成熟度。

3.2 PhantomOS（ASPLOS 2020 及相关工作）

PhantomOS 路线强调 透明远程内存 ：应用无需修改，通过 内核级或用户态拦截 将冷页置于远端，热页留本地。与 Linux AutoNUMA 、回收思路接近，但假设 远端内存带宽优于 SSD swap。

与 Google Software-Defined Far Memory in Warehouse-Scale Computers （ASPLOS 2019）一脉：用 机架级内存 作 swap 后端，论文报告对内存受限 workload 的 显著吞吐提升（相对 SSD swap，引用数据非本文自测）。

3.3 Twilight（EuroSys 2022）

Twilight 等研究探索 CXL 与 RDMA 混合 的页放置：热页本地，温页 CXL，冷页远端池。核心贡献在 策略算法（访问采样、迁移成本模型），而非完整商品 OS。

3.4 学术 vs Linux 主线

维度	学术原型	Linux 6.x 主线
目标	证明可行性、发论文	渐进适配硬件
远程缺页	默认路径	异常路径（尽量本地+CXL）
多主机共享内存	研究热点	CXL 3.0 驱动与策略仍在演进
生产案例	实验集群	云厂商早期实例、on-prem 试点

2026 诚实边界 ：全栈 LegoOS 式部署 几乎仅限实验室 ；生产更多是 "Linux + CXL 作 NUMA 节点 + tiering"。

3.4 PhantomOS 机制补充

PhantomOS 类系统的共同模式：

页访问采样：利用 PTE young bit 或硬件 PEBS
异步预取：在远程缺页前将冷页批量迁出
双路径内存：fast path 本地，slow path RDMA

与 Linux NUMA balancing 的差异：学术原型可 假设 RDMA 延迟稳定 且 专用网络 ；生产环境需与 租户噪声、加密、丢包 共存。

3.5 Twilight 放置算法要点

Twilight 强调 访问频率 × 迁移成本 的在线优化：若 promote/demote 带宽饱和，策略应滞后避免震荡（类似 CPU 调频 governor，见 cpufreq）。内核 memory tiering 的 demotion_scan_period 等 sysctl 体现类似思想。

四、Far Memory 与 Swap 演进

4.1 软件定义远端内存

在 CXL 普及之前，RDMA 远端内存作 swap 已可演示：

bash 复制代码

# 概念：zswap 压缩 + 远端后端（具体实现因发行版而异）
# 参见内核 Documentation/admin-guide/mm/zswap.rst
cat /sys/module/zswap/parameters/enabled

Google Far Memory 论文思路：把远程 DRAM 当作 swap 设备 ，延迟介于 NVMe 与本地 DRAM 之间。Linux swap 子系统的 swap_slots、swap_cluster 与 zswap 压缩栈可对接自定义 swap 后端（需模块或设备驱动支持）。

4.2 zswap 与 zsmalloc

bash 复制代码

# 查看 zswap 是否启用
grep -r zswap /sys/module/zswap/parameters/ 2>/dev/null

zswap 在页提交到块设备前压缩，降低 I/O；与远端内存结合时，压缩率影响 RDMA 流量。调优需同时看内存回收的 swappiness 与 workload 可压缩性。

4.3 CXL 作为第二层内存

CXL 扩展内存在内核中常呈现为 新 NUMA node：

bash 复制代码

numactl --hardware
# 可能出现 node 2+ 对应 CXL 内存
ls /sys/bus/cxl/devices/

应用若盲目 numactl --interleave=all，可能把热数据摊到慢节点------比不绑 NUMA 更差。

五、Linux 适配：CXL 驱动与内存模型

5.1 CXL 子系统

Linux 从 5.x 起合入 drivers/cxl/ 与 Documentation/driver-api/cxl/（版本演进快，以目标内核文档为准）：

CXL Core：总线、端口、decoder 枚举
CXL PCI：绑定扩展器
CXL Memory ：将 HDM（Host-managed Device Memory）纳入 iomem 或 System RAM （DEVMEM vs RAM 模式）

bash 复制代码

# 查看 CXL 设备（需硬件与内核支持）
ls /sys/bus/cxl/devices/
cxl list -M 2>/dev/null || true   # cxl-cli 用户态工具

5.2 与 NUMA 的集成

CXL 内存注册为 pg_data_t 新节点后，现有 API 复用：

mbind、set_mempolicy（见 NUMA）
get_mempolicy 查询
/sys/devices/system/node/nodeN/ 距离矩阵由 ACPI SLIT/CEDT 或固件提供

AutoNUMA 会采样缺页频率并迁移页；对 CXL 节点，迁移 成本模型 必须给远端更高惩罚，否则内核可能错误"平衡"。

5.3 Memory Tiering（`CONFIG_MEMORY_TIERING`）

内核 memory tiering （Documentation/mm/memory-tiers.rst）将节点分为 fast/slow tier：

bash 复制代码

# 查看 tier 分类（接口随内核版本变化）
cat /sys/devices/system/node/node*/tier 2>/dev/null

冷页 demote 到 slow tier（CXL），热页 promote 回 fast tier（本地 DRAM）。demotion 路径与 LRU 回收协同，避免一次性 swap 风暴。

stateDiagram-v2 [*] --> LocalDRAM: 首次分配（优先本地） LocalDRAM --> CXLMem: 采样判定为冷页 CXLMem --> LocalDRAM: 再次频繁访问 promote CXLMem --> Swap: 极端压力 LocalDRAM --> Swap: 内存压力

5.4 HMM（Heterogeneous Memory Management）

HMM 允许设备（GPU、FPGA）与 CPU 共享页表视图 ，处理 设备缺页 与迁移：

mm/hmm.c：核心框架
与 CXL 交叉点：统一 地址空间 上的放置决策------AI workload 大权重 tensor 放 CXL 还是 GPU 显存，需 HMM + 驱动策略

对照页表 x86：远端内存不改变页表格式，改变 物理页来源与 NUMA 策略。

5.5 DAX 与持久内存

DAX（Direct Access） 绕过页缓存，mmap 持久内存或特定 CXL 设备：

bash 复制代码

# 挂载 dax 设备（示例，设备节点因系统而异）
mount -o dax=always /dev/dax0.0 /mnt/pmem

Documentation/filesystems/dax.rst 说明：小原子写 与对齐约束。数据库与键值存储用 DAX 减少复制，但 远 CXL DAX 的延迟特性仍需应用层感知。

5.6 设备 dax vs 系统 RAM 模式

模式	内核处理	适用
System RAM	加入 buddy，普通 `kmalloc`/页缓存	扩展主存
Device DAX	字符设备，用户态 mmap	持久化、数据库

固件 CXL 模式选择错误会导致 容量可见但不可用 或 性能极差------部署检查清单必含 BIOS/CXL 模式。

5.7 内核源码阅读路径

想从源码理解 CXL 内存如何变成 struct page，建议顺序：

drivers/cxl/core/port.c --- 设备发现
drivers/cxl/core/memdev.c --- 内存设备注册
mm/memory-tiers.c --- tier 分类与 demote
mm/migrate.c --- 页迁移到远端节点
mm/numa_memblks.c --- ACPI 内存块与 node 映射

对照 slab 分配器：远端内存上的 kmalloc 仍从对应 node 的 page allocator 取页，对象热 时 L3 cache 行为与本地不同。

5.8 cgroup 与容器内存

cgroup v2 的 memory.max 按 逻辑 cgroup 计数 ，不区分页物理位于本地或 CXL。容器编排器若未暴露拓扑，Pod 可能被调度到 无本地 DRAM 的 CPU 而 cgroup 仍显示"内存未超限"------表现为延迟抖动而非 OOM。

Kubernetes 社区探索 Topology Manager 与 NUMA 感知调度 ；与 CXL 结合时，建议 显式 node 亲和 而非仅靠 cgroup 限额。

六、页面放置与调度协同

6.1 延迟敏感 workload

低延迟服务（交易、实时分析）应：

bash 复制代码

numactl --cpunodebind=0 --membind=0 ./latency_critical

并禁止 AutoNUMA 迁移（echo 0 > /proc/sys/kernel/numa_balancing）或 mbind 锁定。CXL 节点仅用于 明确标注可容忍延迟 的缓存层。

6.2 吞吐型 workload

批处理、扫描、大模型 参数驻留 可用 CXL 作 容量层：

分配大数组时 mbind 到 CXL node
依赖 tiering 自动 promote 热区

6.3 与 CPU 调度器

负载均衡假设 本地内存便宜 。计算节点 DRAM 变小时，线程迁移到 无本地页 的 CPU 会放大远程访问。未来 sched_ext （eBPF 可编程调度）可能接入 内存拓扑代价------2026 主线 CFS 仅部分感知 NUMA。

七、存储解耦与 RDMA

7.1 分离式存储栈

除内存外，NVMe-oF 、Ceph RDMA 已使存储远离计算节点。OS 侧体现为：

网络块设备（nbd、rbd）
io_uring 降低远程存储 syscall 开销
SPDK 用户态绕过内核（见 OS 展望）

内存与存储同时远端时，页缓存 与 readahead 策略需重新调参------远端内存 + 远端盘可能 双重惩罚。

7.2 一致性协议

多主机共享 CXL 3.0 内存池时，硬件可能提供 有限一致性 ；否则需 软件分布式锁页 或 单写者 模型。LegoOS mComponent 即单写者范例；数据库领域更接近 分片 + 本地 DRAM 而非真共享内存。

八、故障域与高可用

8.1 远程内存节点故障

本地 DRAM 页由本机管理；CXL 扩展器或远端 mComponent 故障时：

已映射页 可能突然不可访问 → 内核 OOM 或 SIGBUS
无透明副本 除非应用或 OS 做镜像

生产需 RAID 式内存镜像 （成本极高）或 应用层副本（Redis/Memcached 分片），不能假设"内存池永远在线"。

8.2 热插拔与容量变化

CXL 热插拔触发 内存热添加/移除：

bash 复制代码

# 内存热添加后 node 上线（依赖 ACPI 事件）
dmesg | grep -i cxl
dmesg | grep -i memory-hotplug

内存热插拔篇讨论 CPU；内存侧需处理 zone 迁移 、balloon 回收 、容器 cgroup 上限 联动。

8.3 与机密计算的交叉

池化内存若跨主机，加密密钥域 （SEV-SNP ASID、TDX TD）与 物理页归属 必须一致。当前机密 VM 多假设 内存物理可控 ；机架池化 + 机密计算仍是 开放研究/早期产品，部署前核对云厂商白皮书。

8.4 网络解耦

除内存外，计算节点 可能 无本地 NVMe ，仅通过 NVMe-oF 或 Ceph 挂载卷。此时：

VFS I/O 路径的 readpage 仍走页缓存，但 后备存储 延迟从 μs 级变为 网络 RTT
io_uring 的 IORING_OP_READ 对远程盘收益更大，但 超时与重试 策略需应用层配合

8.5 能耗与散热

池化允许 计算节点薄配置 （少 DIMM 槽），内存集中在大容量扩展器 独立散热风道 。数据中心 PUE 与 机架配平 是采购维度，OS 表现为 node 功耗封顶 与电源管理策略在薄内存节点上更易触发 内存带宽瓶颈 而非 CPU 瓶颈。

九、应用场景与边界

9.1 数据库

缓冲池 大于本地 DRAM：温数据放 CXL
日志仍优先本地 NVMe 或 DAX 持久内存
避免 latch 密集 结构放远内存

9.2 机器学习

模型权重 数百 GB：CXL 容量层 + GPU HBM 热缓存
数据加载 ：io_uring + 本地预读

9.3 虚拟化

Host 用 CXL 作 内存超卖 后端：气球 + tiering
Guest 仍见"物理内存"，Host 负责 远端回填

9.4 不适合场景

硬实时（见 RTOS 巡礼）：远程缺页不可预测
极低延迟交易：跨 CXL 的每次 cache miss 都贵
强一致共享内存 HPC：除非硬件一致性已验证

十、用户态与编程建议

10.1 显式绑定

c 复制代码

#include <numa.h>
#include <numaif.h>

unsigned long mask = 1UL << cxl_node;
mbind(addr, size, MPOL_BIND, &mask, cxl_node + 1, MPOL_MF_MOVE);

10.2 `madvise` 提示

c 复制代码

madvise(cold_region, size, MADV_COLD);   // 提示内核降级到 slow tier
madvise(hot_region, size, MADV_WILLNEED);

内核是否采纳取决于 tiering 与回收策略。

10.3 大页

大页在 CXL 上可减少 TLB miss，但 分配失败 时回退到 4K 页可能跨节点------需检查 /proc/meminfo 的 HugePages_*。

十一、观测与调优

11.1 工具

bash 复制代码

numastat -p $(pidof myapp)
cat /proc/$(pidof myapp)/numa_maps
perf stat -e node-loads,node-load-misses ./workload

11.2 指标

指标	含义
`node-load-misses`	远程节点访问比例
`pgmigrate_success`	tiering 迁移次数
CXL 控制器带宽计数	硬件瓶颈

11.3 与 perf 结合

perf mem 可采样 load 来源 node（需 CPU 支持）。对比绑定前后 CXL node 占比 是验证策略是否有效的最低门槛。

11.4 与 vmstat / sar

bash 复制代码

vmstat 1
sar -r 1

关注 pgscan_direct、pgsteal 激增是否伴随 CXL node 带宽打满 。若 steal 高但 本地 node 仍有余量 ，说明 tiering 策略可能需调 demotion_watermarks。

11.5 容器场景

bash 复制代码

# cgroup v2 内存压力
cat /sys/fs/cgroup/system.slice/memory.pressure

Kubernetes Memory Manager （静态策略）可将容器 ** Guaranteed QoS** 绑定本地 node；Burstable 工作负载更适合放 CXL tier 作 超卖缓冲。

十二、与 BSD / Windows 的对照（简）

OS	CXL / 远端内存
Linux	主线 CXL 驱动、tiering、HMM 最完整
FreeBSD	跟进 PCIe/CXL 设备驱动，NUMA 工具较少
Windows Server	厂商驱动 + NUMA API，池化多由 Azure 栈集成

跨平台中间件应抽象 拓扑发现 ，而非硬编码 node 0。

12.1 Windows Server 与 WSL

Windows 内核通过 NUMA API 与驱动栈暴露远端内存；Azure 栈可能集成 CXL 池化，但 应用开发者 仍主要通过 进程亲和 API 感知。WSL2 Guest 见 Linux 路径。

十三、生产可用边界（2026）

能力	状态
单机 CXL 扩展卡作 System RAM	早期部署，需硬件/内核匹配
CXL 3.0 多主机池化	规范与样机存在，通用 OS 策略不成熟
LegoOS 式全 disaggregated OS	学术原型
Linux memory tiering + AutoNUMA	主线可用，需调优
远端 RDMA swap	定制环境，非默认发行版
K8s 资源声明 CXL	社区探索，非稳定 API

不预测 哪家厂商率先大规模池化；工程上应 在目标硬件上实测 node distances 与故障行为。

十五、选型决策树

flowchart TD Q1{工作集大于本地 DRAM?} Q1 -->|否| LOCAL[仅优化 NUMA 本地] Q1 -->|是| Q2{延迟容忍?} Q2 -->|低| EXPAND[扩容本地 DRAM 或分片] Q2 -->|中| CXL[CXL 扩展 + tiering] Q2 -->|高| FAR[Far memory / 定制 swap] CXL --> Q3{多主机共享?} Q3 -->|是| WAIT[CXL 3.0 + 跟踪内核进展] Q3 -->|否| PROD[单机 CXL 试点]

十六、案例研究框架（非虚构数据）

以下 不引用具体客户数字；给出可复现的评估步骤，供自有硬件试点：

16.1 基准矩阵

场景	命令/工具	观察项
本地 DRAM 带宽	`STREAM` 绑定 node 0	Triad MB/s
CXL 带宽	`STREAM` 绑定 CXL node	与本地比值
随机指针追踪	`lmbench lat_mem_rd`	ns 级曲线
应用代表	生产二进制 + `perf mem`	`node-load-misses`
故障注入	拔扩展器模拟（实验室）	是否 SIGBUS/OOM

16.2 决策记录模板

拓扑：numactl -H 输出存档
策略：memory_tiering、numa_balancing 开关
回滚：关闭 CXL System RAM 模式仅保留本地 DRAM
SLO：P99 延迟相对基线允许劣化百分比（由业务定义）

十七、与 Unikernel / RTOS 的对比

Unikernel 假设 单镜像、静态链接 ，内存规模常极小；disaggregated 内存对 Unikernel 收益有限------镜像本身很少超过本地 DRAM。

RTOS 巡礼的硬实时依赖 有界缺页 ；远程内存引入 无界网络延迟，原则上不兼容硬实时，除非全工作集 pin 在本地。

十八、未来内核可能方向

全局页服务 ：单机的 mm/ 扩展为可插拔 remote page provider（LegoOS 思想的子集）
调度器感知内存距离：sched_ext 策略包内嵌 topology cost
CXL 3.0 多主机 ：设备级锁与租约语义进入内核
与 Rust for Linux：安全地实现远端页元数据管理

18.1 与调度、锁、RCU 的间接关系

可拆分内存不改变 spinlock 与 RCU 语义，但 锁持有期间 若访问 CXL 页，临界区时间 变长，间接放大锁竞争。高锁争用服务迁移到 CXL 前应 profiling 锁等待 （perf lock）。

以上均为 研究或主线演进方向，非 2026 承诺功能。

十九、术语表

术语	含义
CXL.mem	主机 load/store 访问设备内存
HDM	Host-managed Device Memory
tiering	内核热/冷页分层迁移
demote	页从 fast tier 降到 slow tier
Far Memory	机架级远端 DRAM 作扩展
p/m/s Component	LegoOS 计算/内存/存储组件

二十、总结

资源解耦 打破"内存一定本地"假设；CXL.mem 把扩展 DRAM 纳入 load/store 路径。
CXL 2.0/3.0 从单机扩展到机架池化；3.0 的多主机一致性是 OS 重构催化剂。
LegoOS / PhantomOS / Twilight 证明分布式页管理可行，但生产仍以 Linux 渐进扩展 为主。
Linux 通过 CXL 驱动、NUMA 节点、memory tiering 、HMM 、DAX 适配；与 NUMA、swap、缺页深度耦合。
故障域、机密性、调度 是三大未解难题；硬实时与极低延迟场景慎用最远内存层。
与机密计算结合部署时，核对内存加密与池化策略是否冲突。
评估试点 应基于 STREAM/lmbench/perf 与业务 SLO，而非规格表延迟 alone。

十八、读者行动清单

在目标机器运行 numactl -H 与 cxl list，确认是否已有 CXL node。
阅读 Documentation/mm/memory-tiers.rst 对应内核版本。
对延迟敏感服务绑定本地 node；对容量型服务试用 tiering。
跟踪 CXL Consortium 与内核 linux-cxl 邮件列表的版本发布。
阅读下一篇 OS 展望了解 CXL 在十年趋势中的位置。

附录、Linux 6.x CXL 内核命令与观测

以下命令需在 支持 CXL 的硬件 + 匹配内核 上执行；无设备时仅作语法参考，不粘贴虚构输出。

bash 复制代码

# 枚举 CXL 总线与设备（需 CONFIG_CXL）
ls /sys/bus/cxl/devices/

# 查看 NUMA 节点是否含 CXL 内存
numactl -H

# 内存 tiering 相关（随内核版本而异，查 Documentation/admin-guide/mm/memory-tiering.rst）
cat /sys/kernel/mm/memory_tiers/*/tier

调优提示：

将 热工作集 绑本地 DRAM node；冷数据依赖 tiering demotion 到 CXL node。
避免跨 socket + CXL 的双重远访问------对照调度与 NUMA 的 numactl --membind。

与 swap 的关系 ：CXL 扩展内存在压力下是否参与回收，取决于内核 ZSMALLOC / dax 路径与策略；生产应实测 swap 是否触发到 CXL 设备。

附录 1、工程深化：CXL memdev dax 模式

维度	要点	本站交叉引用
机制	CXL memdev dax 模式在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[CXL memdev dax 模式] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 CXL memdev dax 模式纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 2、工程深化：HMM GPU 页迁移

维度	要点	本站交叉引用
机制	HMM GPU 页迁移在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[HMM GPU 页迁移] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 HMM GPU 页迁移纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 3、工程深化：tiering demotion 延迟

维度	要点	本站交叉引用
机制	tiering demotion 延迟在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[tiering demotion 延迟] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 tiering demotion 延迟纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 4、工程深化：LegoOS 组件 RPC

维度	要点	本站交叉引用
机制	LegoOS 组件 RPC 在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[LegoOS 组件 RPC] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 LegoOS 组件 RPC 纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 5、工程深化：PhantomOS 网络内存

维度	要点	本站交叉引用
机制	PhantomOS 网络内存在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[PhantomOS 网络内存] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 PhantomOS 网络内存纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 6、工程深化：Twilight 调度器

维度	要点	本站交叉引用
机制	Twilight 调度器在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[Twilight 调度器] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 Twilight 调度器纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 7、工程深化：云内存池计费模型

维度	要点	本站交叉引用
机制	云内存池计费模型在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[云内存池计费模型] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把云内存池计费模型纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 8、工程深化：far memory swap 实验

维度	要点	本站交叉引用
机制	far memory swap 实验在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[far memory swap 实验] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 far memory swap 实验纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 9、工程深化：numa_balancing 与 CXL

维度	要点	本站交叉引用
机制	numa_balancing 与 CXL 在可拆分 OS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[numa_balancing 与 CXL] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 numa_balancing 与 CXL 纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

参考资料

规范与官方文档（A 级）

CXL Consortium. Compute Express Link Specification, Rev. 2.0 / 3.0
ACPI. CEDT (CXL Early Discovery Table) 相关章节
Linux Kernel: Documentation/driver-api/cxl/, Documentation/mm/memory-tiers.rst, Documentation/mm/hmm.rst, Documentation/filesystems/dax.rst

论文（A 级）

Shan, S. et al. "LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation." OSDI 2018
Guo, H. et al. "Software-Defined Far Memory in Warehouse-Scale Computers." ASPLOS 2019
Wang, D. et al. "Twilight: A New Abstraction for Efficient Remote Memory in Heterogeneous Systems." EuroSys 2022

本站相关

工具

numactl, numastat
cxl-cli / cxl list
daxctl
perf

上一篇 ：机密计算 下一篇 ：OS 的下一个十年

可拆分 OS：CXL 内存池化如何动摇本地 DRAM 假设

一、资源解耦：从一体机到池化

1.1 传统假设

1.2 解耦动机

1.3 与虚拟化的关系

二、CXL 规范与语义

2.1 三代概览

2.2 CXL 2.0

2.3 CXL 3.0

2.4 延迟与带宽的工程口径

三、学术原型：LegoOS、PhantomOS、Twilight

3.1 LegoOS（OSDI 2018）

3.2 PhantomOS（ASPLOS 2020 及相关工作）

3.3 Twilight（EuroSys 2022）

3.4 学术 vs Linux 主线

3.4 PhantomOS 机制补充

3.5 Twilight 放置算法要点

四、Far Memory 与 Swap 演进

4.1 软件定义远端内存

4.2 zswap 与 zsmalloc

4.3 CXL 作为第二层内存

五、Linux 适配：CXL 驱动与内存模型

5.1 CXL 子系统

5.2 与 NUMA 的集成

5.3 Memory Tiering（CONFIG_MEMORY_TIERING）

5.4 HMM（Heterogeneous Memory Management）

5.5 DAX 与持久内存

5.6 设备 dax vs 系统 RAM 模式

5.7 内核源码阅读路径

5.8 cgroup 与容器内存

六、页面放置与调度协同

6.1 延迟敏感 workload

6.2 吞吐型 workload

6.3 与 CPU 调度器

七、存储解耦与 RDMA

7.1 分离式存储栈

7.2 一致性协议

八、故障域与高可用

8.1 远程内存节点故障

8.2 热插拔与容量变化

8.3 与 机密计算 的交叉

8.4 网络解耦

8.5 能耗与散热

九、应用场景与边界

9.1 数据库

9.2 机器学习

9.3 虚拟化

9.4 不适合场景

十、用户态与编程建议

10.1 显式绑定

10.2 madvise 提示

10.3 大页

十一、观测与调优

11.1 工具

11.2 指标

11.3 与 perf 结合

11.4 与 vmstat / sar

11.5 容器场景

十二、与 BSD / Windows 的对照（简）

12.1 Windows Server 与 WSL

十三、生产可用边界（2026）

十五、选型决策树

十六、案例研究框架（非虚构数据）

16.1 基准矩阵

16.2 决策记录模板

十七、与 Unikernel / RTOS 的对比

十八、未来内核可能方向

18.1 与调度、锁、RCU 的间接关系

十九、术语表

二十、总结

十八、读者行动清单

附录、Linux 6.x CXL 内核命令与观测

附录 1、工程深化：CXL memdev dax 模式

附录 2、工程深化：HMM GPU 页迁移

附录 3、工程深化：tiering demotion 延迟

附录 4、工程深化：LegoOS 组件 RPC

附录 5、工程深化：PhantomOS 网络内存

附录 6、工程深化：Twilight 调度器

附录 7、工程深化：云内存池计费模型

附录 8、工程深化：far memory swap 实验

5.3 Memory Tiering（`CONFIG_MEMORY_TIERING`）

8.3 与机密计算的交叉

10.2 `madvise` 提示