Back to news
"Largest number of commits ever, kernel 7.3 brings significant changes in sched-ext, memory management, and GPU drivers"

Linux 7.3 just got released, check Igalia contributions

Linux 7.3 has been tagged and released with over 18,000 commits. Linux 7.3 includes many exciting improvements: sub-scheduler support in sched-ext, which allows BPF schedulers to be hierarchically stacked along the cgroup hierarchy, better tracking of the working set in VM guest memory using userfaultfd(2), improved FUSE performance through better support for buffer pools and zero-copy I/O when used with io_uring, better memory access tracking in DAMON using data attributes, improved VRAM management on older AMD GPUs, and many more. For more details and a full list of changes, check the corresponding KernelNewbies page.

As usual, Igalia has been busy contributing fixes and improvements across the release, especially to GPU drivers and sched-ext. Below are some of our highlights from this cycle.

Igalia Changelog

V3D Submission Path and Performance Monitor Improvements

In this release, we continued improving the Raspberry Pi GPU drivers, especially for the V3D submission path. As the V3D driver grew over time, different types of submissions were added, and the submission code became more complex, but the driver kept the same abstractions. That’s why we refactored the code to introduce a new submission abstraction that represents the submission chain as an ordered array of jobs. This made the code more readable and allowed us to address several minor issues in the submission path, making it more robust.

We also refactored the performance monitor locking, which allowed us to properly enforce cross-queue serialization and improve the reliability of the performance counter values. This will be especially useful for GPU developers, who can use performance counter values for debugging and performance profiling.

This release will also be the last one in which the V3D driver supports V3D 3.3 and 4.1. These V3D generations have had no in-tree userspace since Mesa dropped support for them in 2024, and we will deprecate kernel support in the next release.

AMD GPU Driver Improvements

We have continued with various driver improvements such as refactoring the context and buffer object list handling away from legacy IDR to XArray, while simultaneously simplifying the respective code paths.

We also eliminated several hundred kilobytes from the compiled driver size by moving certain runtime decisions from macros to driver init-time checks.

On the performance front, we reduced CPU utilization in the job submission path by removing the unused buffer object list mutex, replacing multiple invariant IP checks with a single cached conditional, and significantly reduced idle worker re-arming to further reduce CPU usage.

On the security side, we have addressed potential Use-After-Free (UAF) bugs and null pointer dereference bugs in the context pstate handling path.

AMD Display Driver Bug Fixes

We addressed gradient banding in HDR content on AMD display drivers (DCN 3.0+ and DCN3.2+ families). To address this, we provided distinct LUT segmentation for encoded-to-linear EOTFs calculated by the AMD color module when the color block doesn’t support hardware curves, and we translated predefined EOTFs into a PWL LUT. Before these changes, the driver used the same helper and LUT segmentation for EOTFs and inverse EOTFS, but those have different input domains and curvature distributions. We also extended the use of LUTs, rather than hardware curves, for degamma to AMD driver-specific properties when using subsampled formats.

We resolved an issue where missing blend-mode properties triggered continuous warnings across all AMD display versions. Recent kernel updates (starting with version 7.2) require drivers to explicitly advertise supported blend modes rather than relying on DRM’s old default pre-multiplied behavior. This update ensures full compatibility with newer kernels and eliminates system log spam.

DMEM cgroup Improvements

We also got involved in improvements to the dmem cgroup controller, which allows the peak VRAM usage of amdgpu and Xe drivers to be inspected. While setting the max dmem usage to lower than the current actual consumption, the system will now reclaim VRAM memory, moving it to GTT. Low and min settings will now be considered during certain scenarios, triggering reclaim instead of backing off to GTT allocation. For more details, take a look at Cascardo’s blog post about it.

Sched-ext Improvements

We have continued improving sched-ext. In particular, we optimized the BPF-arena spinlock’s memory usage by removing duplicate copies. We also made ops.cgroup_set_bandwidth(), one of the sched-ext hooks for cgroup v2 support, sleepable; this lets a BPF scheduler call a sleepable operation, like memory allocation, giving it more flexibility.

Other General Fixes and Cleanups

Beyond the major subsystem updates, Igalia also helped with several “odd fixes” and general maintenance work to keep the kernel healthy.

We also simplified the nouveau and panthor codebases and continued improving the shared DRM scheduler component.

We fixed an issue in the i915/Xe display code where new enum entries overflowed storage, and we fixed many UAF issues in the AMD KUNIT tests.

We identified and fixed several memory leaks during in KMS atomic modesetting.

We did a minor code cleanup by removing a useless return branch in VFS POSIX ACL code. This unnecessary code was identified while working on the FUSE ACLs caching documentation.

We also clarified console verbosity when using panic_print with pstore. When you want more information during a kernel panic, you can print extra stuff using, for example, the panic_{print,sys_info} parameters to dump memory state, task stacks, etc. This is especially useful for pstore users saving data for post-mortem analysis. What might go unnoticed is how console drivers can impact that. Consoles are known to be slow, and the console verbosity is automatically bumped on panic. In this cycle, we documented this behavior and how it relates to panic extra dumping, so users don’t waste time debugging the panic path itself.


Authored (69)

Changwoo Min

Guilherme G. Piccoli

John Harrison

Luis Henriques

Maíra Canal

Melissa Wen

Thadeu Lima de Souza Cascardo

Tvrtko Ursulin

Reviewed (59)

André Almeida

Christian Gmeiner

Iago Toral Quiroga

Maíra Canal

Melissa Wen

Thadeu Lima de Souza Cascardo

Tvrtko Ursulin

Tested (8)

Thadeu Lima de Souza Cascardo

Acked (2)

Maíra Canal

Tvrtko Ursulin

Maintainer SoB (9)

Maíra Canal

Melissa Wen