【操作系统百科】可拆分 OS

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

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

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

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

flowchart TD
    subgraph rack [机架级资源池]
        CPUPOOL[计算节点池<br/>CPU + 少量本地 DRAM]
        MEMPOOL[内存扩展器池<br/>CXL.mem]
        STORE[存储节点<br/>NVMe / RDMA]
    end
    CPUPOOL -->|CXL.mem load/store| MEMPOOL
    CPUPOOL -->|RDMA / TCP| STORE
    OS[Linux / 研究原型] -->|页分配 / 放置策略| CPUPOOL
    OS -->|HMM / tiering| MEMPOOL

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

1.1 传统假设

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

当 慢内存 的延迟从 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 级）：

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

flowchart LR
    CPU[主机 CPU] -->|本地 DDR| LMEM[本地 DRAM<br/>低延迟]
    CPU -->|CXL.mem| CXLCTL[CXL 控制器]
    CXLCTL --> EMEM[扩展器 DRAM<br/>较高延迟]
    DEV[加速器] -->|CXL.cache| CPU

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 经 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 主线

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 已可演示：

# 概念：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

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

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

4.3 CXL 作为第二层内存

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

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 模式）

# 查看 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：

# 查看 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 设备：

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

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

5.6 设备 dax vs 系统 RAM 模式

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

5.7 内核源码阅读路径

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

1. drivers/cxl/core/port.c — 设备发现
2. drivers/cxl/core/memdev.c — 内存设备注册
3. mm/memory-tiers.c — tier 分类与 demote
4. mm/migrate.c — 页迁移到远端节点
5. 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

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

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 热插拔触发 内存热添加/移除：

# 内存热添加后 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 显式绑定

#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 提示

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 工具

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

11.2 指标

11.3 与 perf 结合

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

11.4 与 vmstat / sar

vmstat 1
sar -r 1

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

11.5 容器场景

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

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

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

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

12.1 Windows Server 与 WSL

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

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

不预测 哪家厂商率先大规模池化；工程上应 在目标硬件上实测 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 基准矩阵

16.2 决策记录模板

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

十七、与 Unikernel / RTOS 的对比

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

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

十八、未来内核可能方向

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

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

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

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

十九、术语表

二十、总结

• 资源解耦 打破”内存一定本地”假设；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。

十八、读者行动清单

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

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

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

# 枚举 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 模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本站相关

• NUMA 内存
• 缺页处理
• swap
• 内存回收
• 伙伴分配器
• 大页
• io_uring 内核内部
• KVM 架构
• 机密计算
• 容器隔离

工具

• numactl, numastat
• cxl-cli / cxl list
• daxctl
• perf

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