110 篇走完——最后一个问题：OS 接下来要解决什么？

一、先看图

flowchart TD
    TREND[趋势] --> AI[AI workload<br/>GPU/TPU/NPU]
    TREND --> HETERO[异构计算<br/>CPU+GPU+FPGA+DPU]
    TREND --> MEM[内存革命<br/>CXL/PMem]
    TREND --> BYPASS[内核旁路<br/>DPDK/SPDK/io_uring]
    TREND --> SAFE[安全<br/>机密计算/Rust]

    classDef trend fill:#a371f722,stroke:#a371f7,color:#adbac7;
    class TREND,AI,HETERO,MEM,BYPASS,SAFE trend

二、AI workload 对 OS 的冲击

2.1 调度

传统调度器为 CPU 密集型设计。AI 训练：

• GPU 调度 → OS 几乎不参与
• CPU 做数据预处理 → 需要与 GPU 协调
• 多机训练 → 网络调度同样关键

2.2 内存

大模型参数 → 数百 GB → 需要 CXL 内存池、GPU 内存管理。

2.3 I/O

训练数据加载 → io_uring + 直接 I/O → 减少 OS 开销。

三、异构计算

CPU + GPU + DPU + FPGA + NPU

每种加速器有自己的调度、内存管理、I/O 栈。

OS 的角色：

• 资源发现和分配
• 统一的内存地址空间（CXL）
• 设备间通信
• 但不做具体的加速器调度

四、内核旁路的未来

趋势：OS 从数据路径退出 → 只管控制路径。

五、sched_ext + ML

SEC("struct_ops/enqueue")
void BPF_PROG(ml_enqueue, struct task_struct *p, u64 enq_flags)
{
    // 用 ML 模型预测最佳 CPU
    int target_cpu = ml_predict(p);
    scx_bpf_dispatch(p, target_cpu, SCX_SLICE_DFL, enq_flags);
}

BPF 可编程调度器 → 可以接入 ML 模型 → 数据驱动的调度决策。

六、OS 与 Runtime 的重新分工

传统：    App → libc → syscall → 内核
未来：    App → Runtime(Wasm/eBPF/GPU) → 少量 syscall → 内核

• WebAssembly → 沙箱 + 近原生性能
• eBPF → 可编程内核
• GPU runtime → 独立调度

OS 退化为”硬件抽象 + 安全隔离 + 资源分配”的最小层。

七、安全的长期演化

八、CXL 内存革命

本地 DRAM → CXL 近端 → CXL 池化 → 持久内存

OS 需要：

• 多层内存管理
• 智能页面放置
• 故障域感知
• 共享内存一致性

九、给读者的下一步

十、小结

• AI + 异构 → OS 从数据路径退出，聚焦控制路径
• CXL → 内存管理革命
• sched_ext → 可编程调度的新纪元
• Rust + 机密计算 → 安全的长期演化
• OS 的核心价值：硬件抽象、安全隔离、资源公平分配

这是【操作系统百科】系列的最后一篇。110 篇文章覆盖了从进程到调度、从内存到文件系统、从中断到安全、从内核到前沿。希望这个系列能帮助你建立系统化的 OS 工程视角。

参考文献

• 本系列全部 109 篇文章
• Ousterhout, “A Philosophy of Software Design.” 2018
• Barroso et al., “The Datacenter as a Computer.” 3rd edition
• LWN.net 长期跟踪

工具

• 本系列提到的所有工具
• bpftrace / perf / trace-cmd → 观测
• crash / kdump → 调试
• Rust + bindgen → 未来

上一篇：可拆分 OS

【操作系统百科】系列完结。感谢阅读。