Linus Torvalds released Linux kernel 7.3 on October 18, 2026 (local time). For gaming, the release strengthens the protection mechanism that helps make efficient use of limited video memory (VRAM), and it improves recovery when the GPU hangs on older Radeon cards. The VRAM management changes come from patches a developer introduced in April this year, which have now been merged into the mainline Linux kernel. However, simply updating the kernel will not automatically prioritize the game in the foreground. To benefit from the improvements, you also need cooperation from the GPU driver and the desktop environment.
VRAM management improvements require coordination among the kernel, drivers, and user space
The strengthened VRAM protection in Linux 7.3 is expected to help most when you launch a game while other apps, such as a browser, have already claimed memory. Natalie Vock, who developed the changes, pointed out in an explanation of the AMDGPU work that even when a game requests that data be placed in VRAM, insufficient free space can cause it to be allocated in the GTT region of system RAM instead. Because the GPU has to go through the PCI bus to access data in this region, it cannot process it as fast as with dedicated VRAM, which can lead to lower rendering performance and unstable frame rates.
A mechanism for evicting data when memory runs low has existed for some time. However, the kernel manages individual buffers, and it cannot determine whether the game the user is actively playing or an app running in the background should take priority. If every app were allowed to claim VRAM preferentially, they would end up evicting each other's data, and transfers between memories would actually increase.
To address this, the system uses "dmem," the device memory management feature of cgroups, which groups processes and controls resource allocation. It protects a specified amount of usage for each group, and when memory runs short, it preferentially evicts unprotected data belonging to other groups. This mechanism was already part of the mainline Linux kernel, so Linux 7.3 does not newly introduce cgroup-based GPU memory management.
The main improvement this time is that protection settings are now applied properly when VRAM is newly allocated. In TTM commit bbc744c062f8, listed in the Linux 7.3 changelog, the behavior was changed so that if an allocation fails even though a cgroup's memory usage is below its protection level (low/min), unprotected buffers are evicted to free up space. This is expected to improve the problem where, after other apps have used up the VRAM first, the data of a game that should be protected is sent to GTT from the start. To use this mechanism, however, you need not only the kernel's protection handling but also a compatible GPU driver and a user-space tool that specifies which apps to prioritize.
| Role | What it handles | What to check when using it |
|---|---|---|
| Kernel | Controls VRAM allocation and eviction based on protection settings | Are you using Linux 7.3, or a kernel that includes equivalent fixes? |
| GPU driver | Links GPU memory with the dmem management mechanism | Does your driver support dmem? |
| User space | Manages protection settings and designates the foreground app as the priority | Are dmemcg-booster and your desktop environment set up to work together? |
This arrangement is based on the user-space tool explanation and FAQ published by Vock. In the method described, dmemcg-booster manages the cgroup protection settings, while plasma-foreground-booster for KDE Plasma reports which app is running in the foreground. For environments other than KDE, the guide also describes using a newer version of gamescope that supports this, but dmemcg-booster is still required in that case.
In other words, the desktop decides which app to prioritize, and the kernel handles memory management based on that information. However, because the tools described depend on systemd, the same steps may not apply as-is to different system configurations. Which features you can use will also vary depending on GPU driver support and whether your distribution provides the necessary packages.
Recovery from GPU hangs also improves on older Radeon cards
For older Radeon cards, a change adds IP-block-level soft reset as a recovery method for graphics and compute on the GFX6, GFX7, and GFX8 generations. Rather than resetting the entire GPU, it aims to add recovery paths that reinitialize only the functional block where the problem occurred, limiting the impact on other workloads. In a commit for GFX6, developer Timur Kristóf explained that the conventional ASIC reset erased the contents of VRAM, which could affect not only the offending app but the entire desktop session. For GFX7, there was no effective recovery method for Kaveri and Kabini, so a GPU hang required manually restarting the PC. On Hawaii and Bonaire, meanwhile, VRAM contents were lost during a reset. This change is meant to enable recovery in such situations without resetting the whole GPU.
Test targets for GFX8 included the Radeon RX 570, RX 560, and RX 550, and operation was also confirmed on the Fiji-generation R9 Nano. However, these were verified with Vulkan's hard_reset_cp_wait test, which hangs the GPU by deliberately waiting indefinitely for an event that never occurs. This does not guarantee reliable recovery from every game crash, nor is it a performance measurement showing higher average frame rates. Even so, for users who continue to use older graphics cards, reducing cases where a GPU fault leaves the entire desktop unusable has practical value.
Support for Steam Controller and MSI Claw, plus updated CPU time allocation
On the gaming hardware side, an initial driver for the 2026-model Steam Controller has been added. According to the commit by developer Vicki Pfau, it supports functionality comparable to the existing Steam Deck driver. Support for a new controller has advanced in the mainline Linux kernel, but that does not mean everything is in place, from in-game settings to distribution support.
For the MSI Claw, an HID driver that handles the built-in gamepad's settings has been added. In its initial form, it supports switching gamepad modes, configuring M-key behavior, and a reset function. This means Linux can manage device-specific settings, not just receive input from the controller.
Changes were also made to the CPU scheduler. A new concur mode was introduced for the mechanism that allocates CPU time based on cgroup weights, and it has been set as the default mode. It calculates weights by taking into account the number of concurrently runnable tasks and the number of CPUs, and it is a resource allocation improvement distinct from VRAM protection. CPU time allocation can affect game behavior too, but no performance gain applicable to all titles can be derived from this change.
Whether you can use the improvements depends on your distribution's configuration
With the VRAM protection improvements merged into the mainline Linux kernel, users of distributions that adopt Linux 7.3 no longer need to apply and manage the relevant kernel patches individually. In an addendum to the developer's blog, Vock also advises that after updating to 7.3, users only need to install the user-space tools. Whether the feature actually works, however, depends on whether the distribution's kernel, GPU driver, the mechanism that reports the foreground app, and the cgroup protection settings are combined appropriately.
Also, reducing contention with background apps is a separate challenge from optimizing for cases where a game itself needs more memory than the physical VRAM capacity. In a follow-up published on August 17, Vock explained that the patches addressing the former were merged for Linux 7.3, and also described the development status of work to improve the latter. At that point, a custom kernel and a Mesa development branch were offered for testing later changes, and not all of the improvements described there are included in standard Linux 7.3.
Furthermore, whether integrated GPUs, which have no dedicated VRAM and share system RAM with the GPU, see similar benefits will require separate verification. This update does not increase physical VRAM capacity; it improves how limited memory is allocated and how the system recovers from GPU faults. Once distributions have the kernel, GPU drivers, and user-space tools working together, users should be able to benefit from the improved VRAM management without applying patches themselves.