Linux 7.2

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. 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.

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!

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.

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.

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.

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.

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.

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.

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.