本文选自 Horizon 2026年9月1日技术简报。
摘要
Linux 7.3-rc1 的合并窗口纳入超过 1.5 万个非合并变更集，是内核历史上提交量靠前的一次更新。数量并不是重点，变化的方向更值得关注：BPF 获得更灵活的数据与指针能力，sched_ext 子调度器逐步完整，BTF 动态探针、虚拟机工作集跟踪、DAMON、FUSE 与 io_uring 等机制继续增强。它们共同反映出 Linux 正在适应云原生、AI 集群、用户态存储和精细化资源管理的需求。对普通用户而言，这不是一次需要追逐的“功能大版本”；对基础设施团队而言，却可能影响调度、可观测性、内存分层和高性能 I/O 的下一阶段设计。
合并窗口意味着什么
Linux 每个开发周期开始时会开放合并窗口，各子系统维护者把已经评审和测试的新功能提交给主线。窗口关闭后发布 -rc1，后续候选版本以修复问题为主。提交数量能够反映开发活动，但不能直接代表用户价值：一次机械重构可能包含大量提交，一个关键机制也可能只改动少量代码。
7.3-rc1 合入约 15,267 个非合并变更集，成为历史上规模较大的一次合并。变化覆盖架构、调度、BPF、跟踪、内存、文件系统和虚拟化。企业不应直接把 rc 内核用于生产，而应先识别与自身工作负载相关的子系统，跟踪候选版本中的回归修复，待稳定版进入发行版或云平台后再验证。
sched_ext：把调度策略从内核深处移到可编程层
传统 Linux 调度器运行在内核中，修改策略需要内核开发经验和严格的合入过程。sched_ext 允许通过 BPF 实现扩展调度器，使研究者和基础设施团队能够更快试验面向特定工作负载的 CPU 调度策略。若扩展调度器异常，系统可以回退到内置调度器，降低实验风险。
所谓子调度器能力，是在一个 sched_ext 框架下进一步组织多套调度逻辑。大型集群中的前台服务、离线任务、编译、数据库和 AI 数据预处理具有不同延迟与吞吐目标，一套全局策略难以兼顾。子调度器可以按 cgroup、任务类别或资源域执行更细粒度管理。
这并不意味着每家公司都应该自己写调度器。调度策略会影响公平性、尾延迟、功耗和故障表现，测试复杂度很高。更现实的价值是让云厂商、数据库团队和 AI 基础设施团队能够在不长期维护内核分叉的情况下验证策略，并将有效方案以可观察、可回退的方式部署。
BPF 从观测工具走向通用内核扩展机制
BPF 已从网络包过滤演化为 Linux 可编程基础设施。7.3 的改进包括全局 per-CPU 数据访问、arena 指针传递简化、验证器错误信息增强，以及针对特定并发场景的安全标志。per-CPU 数据能减少多个 CPU 对同一缓存行的争用，适合统计计数与热路径状态；arena 提供内核与 BPF 程序之间更灵活的共享内存表达。
BPF 的关键价值来自验证器。程序加载前，验证器检查内存访问、指针状态、循环和调用路径，尽量保证代码不会破坏内核。能力越强，验证器状态空间也越复杂。更清晰的错误报告看似只是开发体验改进，实际上能降低高级 BPF 功能的使用门槛，否则工程师常常只能面对难以理解的拒绝原因。
对工业与 AI 平台而言，BPF 可用于跟踪容器网络、系统调用、I/O 延迟、调度等待和 GPU 任务周边的 CPU 行为。它不取代应用指标，而是补足“请求为什么在内核层变慢”的证据。生产部署仍需限制程序来源、锁定加载权限，并评估观测本身的开销。
工作集跟踪与 DAMON：AI 集群也需要更精细的内存视角
虚拟机和容器常配置较大的逻辑内存，但某一时间段真正频繁访问的页面只占一部分，这部分称为工作集。准确识别工作集，有助于内存超配、迁移、回收和冷热分层。7.3 纳入的相关跟踪能力，为虚拟化环境提供更细的访问证据。
DAMON 是 Linux 的数据访问监控框架，通过采样了解内存区域的访问模式，控制开销后为回收、分层和优化提供依据。随着 CXL 内存、持久内存和不同性能层级出现，操作系统需要判断哪些页面应留在快速内存，哪些可以迁往容量层。AI 推理服务器除模型权重外，还承载 KV Cache、检索索引和预处理数据，内存行为越来越复杂，这类机制会比单纯增加容量更重要。
工作集数据不能直接等同于业务价值。短期冷页面可能在关键时刻被访问，激进迁移会造成抖动。生产策略应结合服务等级目标、缺页代价和硬件拓扑，并通过灰度实验观察高分位延迟。
FUSE 与 io_uring：用户态文件系统继续逼近高性能路径
FUSE 允许在用户态实现文件系统，开发和隔离更方便，但传统路径需要频繁在内核与用户态之间切换并复制数据。io_uring 通过共享环形队列和异步提交减少系统调用开销。两者结合后，缓冲池管理和零拷贝 I/O 的改进，有机会降低用户态存储的性能损失。
这对对象存储网关、加密文件系统、远程文件系统、容器镜像和 AI 数据集挂载都有意义。训练任务读取大量小文件时，元数据与上下文切换可能成为瓶颈；推理平台加载权重和适配器时，也希望减少不必要复制。不过零拷贝不等于零成本，页面固定、生命周期管理、NUMA 位置和错误恢复仍需谨慎处理。
文件系统与兼容性变化
本周期还包含 NTFS 备用数据流、WOF 压缩只读支持、NFS 目录委托通知、ksmbd 对 Time Machine 等场景的增强，以及 F2FS 动态移除和恢复分区。Btrfs 移除旧版空闲空间缓存和部分历史选项，则提示管理员在升级前检查文件系统格式与挂载配置。
内核升级的风险常来自边缘兼容性，而非新闻标题中的新功能。企业应维护硬件、文件系统、驱动和安全模块的测试矩阵，用真实业务回放验证网络、存储、调度与功耗。对于长期支持发行版，还要区分主线新功能与之后是否会被回移植。
“LLM 辅助内核代码”应如何评价
合并窗口材料提到一部分核心代码获得大模型辅助，这会引发对内核质量的担忧。判断代码不应只看生成方式，而应看作者责任、设计讨论、评审、测试、静态分析和长期维护。内核代码运行在最高权限级别，任何未理解的自动生成代码都不可接受；但大模型用于草拟重复代码、生成测试或帮助理解接口，并不天然降低质量。
更重要的问题是可追责性。提交者必须理解每一行代码，说明设计依据，回应维护者评审，并在问题发生后继续维护。项目也需要明确自动化工具的披露规范和数据安全边界。大模型可以缩短编写时间，却不能替代维护者体系。
结语
Linux 7.3 的价值不在“提交数第二”这一纪录，而在可编程调度、BPF、内存观测和用户态高性能 I/O 等机制正在逐渐成熟。它们为云平台和 AI 基础设施提供了更丰富的控制面，也把更多复杂性带给运维团队。合适的做法是围绕实际工作负载选取能力，建立基准和回退方案，而不是为了版本号升级。内核创新最终要经过稳定性、可观测性与长期维护三道检验。
参考资料
- LWN.net, The End of the 7.3 Merge Window
- Linux Kernel Documentation, Extensible Scheduler Class
- Linux Kernel Documentation, BPF Design and Q&A
- Linux Kernel Documentation, DAMON: Data Access MONitor
- Linux Kernel Documentation, io_uring and FUSE Interfaces