Linux 7.2

“Second busiest cycle ever, kernel 7.2 brings great advances on both CPU and GPU scheduling” Aug 19, 2026 “史上第二繁忙的开发周期，Linux 7.2 内核在 CPU 和 GPU 调度方面带来重大进展” 2026年8月19日

Linux 7.2 was tagged and released this week, on the regular schedule. This cycle was one of the busiest ever, only been beaten by 6.7. This is considered the “new normal”, given that the last 3 or 4 cycles had been pretty busy, especially regarding fixes. Linux 7.2 已于本周按计划打标并发布。这是史上最繁忙的开发周期之一，仅次于 6.7 版本。考虑到过去三四个周期（尤其是修复工作方面）一直非常繁忙，这已被视为“新常态”。

There’s some interesting achievements this cycle, like cache-aware scheduling, improvements on MGLRU, the concept of sub-schedulers for sched_ext (a good introduction on the topic by LWN), automatic creation of multi-size transparent hugepages (also a good intro on LWN) and more - check the LWN articles (part 1 and part 2) for the full picture. 本周期包含了一些有趣的成就，例如缓存感知调度（cache-aware scheduling）、MGLRU 的改进、sched_ext 的子调度器概念（LWN 对此有很好的介绍）、多尺寸透明大页（multi-size transparent hugepages）的自动创建等——详情请查阅 LWN 的文章（第一部分和第二部分）。

Igalia as usual had a good share of contributions, mainly the DRM scheduler fair policy, which had a regression reported at the 11th hour (see below), hence is present as opt-in. Other than that, we landed very nifty runtime power management for GPUs in the Raspberry Pi 4 and 5, improvements in sched_ext, futex, and general bugfixing. Let’s review the highlights! Igalia 一如既往地贡献良多，主要包括 DRM 调度器的公平策略（fair policy）。由于在最后一刻报告了回归问题（见下文），该功能目前作为可选（opt-in）项提供。此外，我们还为树莓派 4 和 5 的 GPU 实现了非常实用的运行时电源管理，并对 sched_ext、futex 进行了改进，以及进行了一般的错误修复。让我们回顾一下重点！

Igalia Changelog

Igalia 更新日志

DRM scheduler fair policy DRM 调度器公平策略

For this release cycle we planned to land and enable the DRM scheduler fair policy which brings significant improvements in scenarios where multiple clients are sharing the GPU, and also when a light interactive client competes for the GPU with a demanding one. Unfortunately, due a last-minute regression report during the 7.2-rc7 week, the default policy will remain the old first-in/first-out (FIFO) scheduler. As the fix for the fair policy regression is already known and early testing looks promising, we are hopeful it will get re-enabled in a next kernel release. 在本发布周期中，我们计划引入并启用 DRM 调度器公平策略。该策略在多个客户端共享 GPU，以及轻量级交互式客户端与高负载客户端竞争 GPU 的场景下，带来了显著改进。遗憾的是，由于在 7.2-rc7 周期间报告了最后一刻的回归问题，默认策略将保留为旧的先进先出（FIFO）调度器。由于公平策略回归问题的修复方案已经明确，且早期测试结果乐观，我们希望它能在下一个内核版本中重新启用。

sched_ext sched_ext

We improved sched-ext observability to simplify debugging. When a custom sched-ext scheduler hits a runtime error – such as failing to schedule a task for over 30 seconds – the kernel ejects it and reverts to the default scheduler. To help diagnose these failures, the kernel dumps the status of each CPU. However, especially on high-core systems, these dumps can be truncated due to buffer size limits between kernel space and user space. We mitigated this by prioritizing the exit CPU (the CPU that triggered the error) so it is dumped first, while also surfacing its CPU ID directly to BPF schedulers and userspace tools. 我们改进了 sched-ext 的可观测性以简化调试。当自定义的 sched-ext 调度器遇到运行时错误（例如超过 30 秒无法调度任务）时，内核会将其剔除并恢复为默认调度器。为了帮助诊断这些故障，内核会转储每个 CPU 的状态。然而，特别是在高核心系统中，由于内核空间和用户空间之间的缓冲区大小限制，这些转储信息可能会被截断。我们通过优先处理触发错误的 CPU（exit CPU）来缓解这一问题，使其被优先转储，同时将其 CPU ID 直接暴露给 BPF 调度器和用户空间工具。

Power Management to Raspberry Pi GPUs and more 树莓派 GPU 的电源管理及其他

In this release, we landed support for Runtime Power Management on the Raspberry Pi 4 and 5 GPUs. Until now, the V3D driver had a very simple power model: the GPU clock was enabled during probe and remained enabled for the entire lifetime of the driver. Although this approach was simple and functional, it meant that an idle GPU would still consume power even when it was not actively executing jobs. With Runtime PM, the GPU is powered only when it is actually processing work, and its clock can be disabled while the GPU is idle. This reduces power consumption when the Raspberry Pi is not using the GPU. We wrote a blog post about this feature with more details and some power measurements. 在此版本中，我们为树莓派 4 和 5 的 GPU 实现了运行时电源管理（Runtime PM）支持。此前，V3D 驱动程序的电源模型非常简单：GPU 时钟在探测期间启用，并在驱动程序的整个生命周期内保持开启。虽然这种方法简单且有效，但意味着空闲的 GPU 即使在不执行任务时也会消耗电力。通过 Runtime PM，GPU 仅在实际处理工作时才通电，并在空闲时关闭时钟。这降低了树莓派在不使用 GPU 时的功耗。我们撰写了一篇关于此功能的博客文章，提供了更多细节和功耗测量数据。

We also fixed two long-standing bugs in the Raspberry Pi 3 GPU driver that had been affecting RetroPie users for years, causing random GPU hangs and complete system crashes. The problems were traced to how the kernel handled tile memory when the GPU ran out of space while processing a frame. Our fixes ensure that each graphics job only writes to its own memory area and that reused memory is properly cleared before being used again, preventing stale or corrupted data from reaching the GPU. With these fixes, RetroPie users should no longer experience the crashes that could occur while navigating the menus. Finally, we landed several fixes for GPU resets on Raspberry Pi 4 and 5, making the reset process more reliable and consistent. 我们还修复了树莓派 3 GPU 驱动程序中两个长期存在的错误，这些错误多年来一直困扰着 RetroPie 用户，导致随机的 GPU 挂起和系统崩溃。问题根源在于 GPU 在处理帧时空间不足时，内核处理平铺内存（tile memory）的方式。我们的修复确保每个图形任务仅写入其自己的内存区域，并且重用内存前会正确清除，防止陈旧或损坏的数据到达 GPU。通过这些修复，RetroPie 用户在浏览菜单时不再会遇到崩溃。最后，我们针对树莓派 4 和 5 的 GPU 重置进行了多项修复，使重置过程更加可靠和一致。

Futex tests and documentation Futex 测试与文档

We continue to work to improve and maintain futex(), an important system call used by all types of workloads to create synchronization mechanisms. In this cycle, we helped to design and land a solution for a 14 year old bug that has been affecting the robust list mechanism with data corruption in some edge cases. 我们继续致力于改进和维护 futex()，这是一个被各类工作负载用于创建同步机制的重要系统调用。在本周期中，我们协助设计并落地了一个针对 14 年前遗留 Bug 的解决方案，该 Bug 在某些极端情况下会导致健壮列表（robust list）机制的数据损坏。

General bugfixing 常规错误修复

We have fixed a long-standing issue in the ueagle-atm driver, which could hit a race condition between kernfs create and remove operations during device probe and disconnect, through the request_firmware API, and generated several bug reports in syzbot over the years. We helped to improve the correctness of the inline-assembly implementation of memcmp() used during x86 boot, preventing subtle potential bugs due to compiler optimization and instruction reordering. 我们修复了 ueagle-atm 驱动程序中一个长期存在的问题，该问题在设备探测和断开连接期间，通过 request_firmware API 在 kernfs 创建和删除操作之间引发竞争条件，多年来在 syzbot 中产生了多个错误报告。我们还帮助改进了 x86 启动期间使用的 memcmp() 内联汇编实现的正确性，防止了因编译器优化和指令重排序导致的潜在隐蔽 Bug。

Towards full HDMI 2.1 support 迈向完整的 HDMI 2.1 支持

Part of the HDMI 2.1 Fixed Rate Link (FRL) support released in this version dates back to the work of Rodrigo Siqueira from Igalia during his time at AMD. This work implements the initial support that allows the amdgpu driver to communicate with HDMI 2.1 monitors (primarily the FRL implementation). This implementation was outside the main code for several years before being incorporated into the source code, with some parts kept virtually as originally written and others reworked throughout the process. At Igalia, we have experience with various DRM/KMS drivers, and this hands-on experience with HDMI 2.1 features complements the knowledge necessary for vendors to enable cutting-edge features to their own drivers. 此版本中发布的 HDMI 2.1 固定速率链路（FRL）支持，部分源于 Igalia 的 Rodrigo Siqueira 在 AMD 工作期间的成果。这项工作实现了初步支持，允许 amdgpu 驱动程序与 HDMI 2.1 显示器通信（主要是 FRL 实现）。该实现被排除在主代码库之外多年，直到现在才被合并，其中部分代码几乎保持原样，而其他部分在过程中进行了重构。在 Igalia，我们拥有各种 DRM/KMS 驱动程序的经验，这种对 HDMI 2.1 特性的实践经验，补充了供应商为其自身驱动程序启用前沿功能所需的知识。