Linux 7.2：缓存感知调度、存储优化与一场更忙的内核迭代

Linux 7.2 已于 8 月 16 日正式发布。这一版并非只增加某个醒目的桌面功能，而是把改进分散在 CPU 调度、存储路径、文件系统、硬件驱动和内核清理等多个层面。对使用复杂多芯片或多路处理器、NVMe 存储、Btrfs，或者较新 Apple、AMD、Intel 硬件的用户来说，更新价值可能更明显。与此同时，长达约九周、拥有超过 2,100 名贡献者的开发周期，也让 AI 辅助开发带来的审查负担成为焦点。

最大亮点：让调度器理解 CPU 缓存拓扑

Linux 7.2 引入了由 CONFIG_SCHED_CACHE 控制的缓存感知调度功能。过去，调度器并不会始终把共享数据的任务安排在同一个末级缓存（Last-Level Cache，简称 LLC）域内；新机制则会尝试将相关任务放置在共享 LLC 的核心上。

这样做的目标，是减少数据在不同缓存域之间来回移动造成的缓存抖动和缓存未命中。对于采用复杂多芯粒或多插槽布局的 AMD EPYC、Intel Xeon 等平台，这类优化尤其值得关注。

不过，这并不是打开后所有电脑都会自动变快的“万能开关”。实际收益取决于处理器的缓存拓扑以及具体工作负载。更准确地说，它针对的是这样一类场景：相关任务被分散到不同缓存域后，产生了本可避免的额外数据搬运和访问开销。

存储优化瞄准 I/O 路径上的实际瓶颈

Linux 7.2 的性能改进很大一部分发生在底层 I/O 路径，而不是用户界面层面：

• 管道写入（pipe write）改动在不同工作负载和测试配置下，报告了约 6% 至 28% 的吞吐提升。
• ext4 重做了 fast commit 路径，目标是减少锁竞争和死锁风险，同时加快目录哈希处理。
• iomap 相关优化改善了 ext4 和 XFS 的部分路径。在高 IOPS 的 NVMe 存储、配合 io_uring 的测试中，部分场景出现性能提升，但这并不代表所有磁盘和应用都能获得相同收益。
• Btrfs 的大 folio 支持不再属于实验性功能，现已默认启用；新版本还加入了最大 2 MB 的巨型 folio 实验性支持。
• exFAT 进一步迁移到 iomap 基础设施，覆盖缓冲 I/O、直接 I/O 及相关操作。重负载测试显示出明显提升，但具体结果仍取决于工作负载，不能视为所有 exFAT 用户都能获得的固定百分比增益。

因此，Linux 7.2 的“更快”并不是来自单一优化，而是由多个子系统共同构成。更可能受益的，是依赖 CPU 缓存局部性、文件系统元数据处理、高吞吐存储、进程间管道通信，或 Btrfs 内存管理的工作负载。

硬件支持继续扩展：Apple、AMD、Intel 和 NVIDIA 都有进展

这次发布包含多个具有里程碑意义的平台支持更新：

• 通过上游 Asahi Linux 的持续工作，Apple M3 MacBook 现在可以使用主线内核启动到串口控制台。这是重要的硬件 bring-up 进展，但还不等于所有 MacBook 组件都已经拥有完整、成熟的桌面支持。
• Intel 获得 USB4STREAM 支持。该协议用于通过 USB4 线缆传输数据流。
• AMDGPU 获得初步 HDMI 2.1 Fixed Rate Link（FRL）支持；AMD 平台代码也加入了面向 Zen 6 的早期准备工作。
• Intel Xe 驱动加入初步 CRI 平台支持，Nouveau 通过 GSP 支持 NVIDIA GA100 计算加速器，Apple Silicon 则获得电池电量报告改进。
• Rust 支持扩展到 IBM s390 架构，使开发基于 Rust 编写的内核组件时可覆盖更多平台。

此外，Linux 7.2 还涉及网络、虚拟化、安全、嵌入式系统和电源遥测等领域。换言之，这既是一版性能更新，也是一次重要的平台支持扩展。

删除旧代码：超过 13,000 行 i486 浮点模拟代码退场

Linux 7.2 删除了超过 13,000 行 的 i486 x87 浮点运算模拟代码，同时移除了 AppleTalk，以及对旧式 ISA 和 PCMCIA ARCnet 网络适配器的支持。

x86 平台现在还无条件要求具备可用的时间戳计数器（TSC）。现代 x86 电脑通常早已依赖 TSC，因此这一调整主要影响极其老旧或非常特殊的硬件，而不是当前的桌面电脑和服务器。

本轮开发还完成了一项持续多年的清理工作：内核代码树不再使用已弃用的 strncpy() API，改用更明确的字符串处理函数。这样的改动不一定会直接带来可感知的性能提升，却有助于减少长期维护中的歧义和潜在问题。

GPU 调度器在发布前回滚：稳定性优先于新模型

Linux 7.2 的开发过程中一度加入了新的“更公平”GPU 调度器，希望改善 GPU 任务的排序方式。但由于 AMD 显卡出现回归问题，开发者在正式发布前将其回滚为 FIFO 调度。

这次回滚说明，开发周期中出现过的功能并不一定会原样进入稳定版本。面对图形回归，维护者选择了更可预测的行为，而不是为了功能数量坚持发布更激进的调度模型。

九周开发周期：内核代码树正在变得更拥挤

Linux 7.2 的开发周期约为九周，参与者超过 2,100 人，并创下据报道的合并窗口参与人数纪录。相关分析还指出，约 5% 的提交带有 AI 辅助标记。

这里的重点并不是 AI 独立编写了 Linux 7.2 的主要功能。更大的变化在于，AI 工具正在带来更多漏洞报告、建议补丁、代码审查结果和后续修复。部分最终被接受的修改，确实用于解决 AI 辅助分析发现的问题；但对每一份报告或补丁，人类维护者和审查者仍需要投入时间核实、修改并决定是否合并。

Linus Torvalds 所说的“新常态”，更像是对开发运作现实的无奈接受，而不是降低审查标准的背书。Linux 7.2 最终按计划发布，但后期规模偏大的更新和持续增加的修补工作，也说明内核项目必须更加谨慎地处理代码量、回归风险与补丁质量。

Linux 7.3 与 Ubuntu 26.10 接下来怎么走？

Linux 7.2 发布后，Linux 7.3 的合并窗口立即开启。据报道，当时已经有约 40 个拉取请求等待处理，接下来几周将决定 7.3 会纳入哪些主要变化。

对于 Ubuntu 26.10，Canonical 内核团队目前已将 Linux 7.2 确定为目标版本。Ubuntu 26.10 计划于 2026 年 10 月 15 日发布，内核冻结时间为 10 月 1 日。从时间安排看，7.2 是更成熟、更稳妥的目标；不过，如果测试发现严重回归或集成问题，发行版最终方案仍可能调整。

对内核开发者而言，下一步是继续进行回归测试和代码审查。对普通用户而言，真正值得关注的并不是 Linux 7.2 的功能列表有多长，而是自己的硬件和工作负载是否正好对应它的强项：缓存局部性、文件系统吞吐、新平台支持，或更完善的设备驱动。