The release status is equally important. As of August 29, 2026, Linux v7.2 was the newest mainline release tag. The dmem cgroup eviction support had been merged into the Linux 7.3 development tree, but Linux 7.3 itself remained unreleased. Separately, a TTM and drm_exec locking patch series addressing severe VRAM contention was publicly proposed for review. The available evidence does not establish that this latter series was merged for Linux 7.3.
The merged 7.3 work: device-memory cgroup eviction
The confirmed mainline change is described as dmem cgroup eviction support, with low-VRAM use cases, including Steam Machine-like systems, explicitly identified as a reason for it.
A device-memory cgroup, often shortened to dmem cgroup, extends Linux’s cgroup resource-management model to device-memory regions. Its documented controls include:
dmem.max, which can impose a limit;dmem.min, which represents a protected minimum; anddmem.low, which provides a lower level of protection under pressure.
Their documented semantics follow Linux’s established memory-cgroup model. The practical significance is that user space can, in principle, organize workloads into groups and express policy about which ones should face limits or receive more protection when device memory is scarce.
That is more nuanced than saying Linux will automatically reserve VRAM for whichever game is in the foreground. The kernel interface does not identify a game, create a cgroup for it, select the desired policy, or assign every competing GPU process to a suitable group. For a user-visible benefit, the relevant hardware and driver path must support the feature, and user-space software must apply a meaningful policy.
In other words, this is an enabling mechanism for resource arbitration. It is not a universal game-performance switch.
A separate TTM proposal is not confirmed as merged
Discussion around low-VRAM DRM work also includes a patch series from Natalie Vock concerning TTM and drm_exec locking during eviction. TTM is a graphics-memory management component used in relevant DRM paths.
The series describes frequent instability and random crashes under strong VRAM contention, attributes the problem to improper TTM eviction behavior, and proposes using drm_exec to lock objects during TTM eviction. Its stated objective is to handle deadlocks more gracefully and avoid -ENOMEM allocation failures as readily in heavily contended domains.
Those are potentially meaningful reliability goals. A memory-management path that fails less readily during intense contention could improve the behavior of affected workloads. But this work must be described carefully: the supplied evidence identifies it as a patch series, not a mainline commit. It is therefore proposed or under review, rather than confirmed Linux 7.3 code.
It should also not be conflated with the merged dmem cgroup change. The two efforts address related aspects of memory pressure but have different roles:
- Dmem cgroups provide a policy framework for limits and protection among groups of workloads.
- The proposed TTM/
drm_execseries targets the locking and eviction mechanics that can contribute to failures under severe contention.
Either could matter to an eventual low-VRAM experience, but neither establishes that every VRAM shortage can be handled gracefully.
Better policy does not create more VRAM
VRAM is the GPU’s local memory, used for resources such as textures, buffers, and render targets. A game or desktop workload can demand more of it than a GPU has available. When that happens, the system has difficult choices: reclaim or evict resources, move data elsewhere, reduce demand, or fail an allocation.
Better eviction policy can affect which data remains resident and which allocation becomes a victim under pressure. It may therefore help prevent a less important workload from displacing resources needed by a more important one. But it cannot add physical local memory to the graphics card.
When demand exceeds available VRAM, data can still spill into system memory. That may be preferable to an immediate failure, but system RAM is not a replacement for local GPU memory. Moving or accessing data outside local VRAM carries a cost. Depending on the application and workload, that cost can appear as stutter, inconsistent frame times, long loading behavior, lower performance, or multiple symptoms at once.
Testing of related VRAM-prioritization work on a Radeon RX 6500 XT with 4GB of VRAM illustrates why expectations should remain measured. One tested game, Alan Wake II, showed a substantial improvement, while several other games showed little or no average-frame-rate change. The report also noted the fundamental constraint: the work did not reduce a game’s VRAM requirement, and demand beyond physical VRAM still spilled into system RAM.
That does not make a policy improvement unimportant. Avoiding a disruptive eviction event or an allocation failure can be valuable even if average FPS barely changes. Equally, a striking result in one title does not prove a general cure for low-VRAM hardware. Results depend on the game, settings, memory behavior, driver stack, and the exact hardware configuration.
Why older Radeon claims remain conditional
It would be easy to turn this into a broad claim that Linux 7.3 gives an aging AMD GPU something it never had on Windows. The available information does not support that conclusion.
No particular Radeon model has been identified. Its architecture, VRAM capacity, Linux graphics driver path, and relationship to the affected DRM code are all unknown. There is also no specified distribution, kernel build, Mesa version, game, graphics API, settings profile, or repeatable before-and-after test.
Those details determine whether a result can be meaningfully attributed to a kernel change. An older AMD GPU may use a driver path that does not exercise the relevant code as assumed. It may be limited by GPU compute performance rather than VRAM. Or it may face a workload whose memory demand is simply too large for policy improvements to make a material difference.
The responsible conclusion is conditional: merged dmem cgroup eviction support may be useful on compatible low-VRAM Linux systems, but a benefit for an unspecified older Radeon GPU has not been demonstrated.
The same caution applies to the proposed TTM locking work. Its authors describe a problem under strong contention and a technically targeted response, but there is no supplied reproducible result showing that it improves a given legacy Radeon card, Linux distribution, or game. Nor is it established as merged Linux 7.3 work.
Windows already has related residency tools
The idea that Windows lacks comparable concepts is too broad. Microsoft documents several Windows graphics-memory mechanisms that address related problems.
WDDM 2.0, available from Windows 10, assigns processes video-memory residency budgets and includes mechanisms called MakeResident, Evict, and TrimResidency. Direct3D 12 also exposes residency priorities for pageable objects. Microsoft further documents that, as a last resort, the system can shift discrete-GPU heaps from video memory to system memory.
These facilities do not mean Windows and Linux have identical policy models or identical outcomes. Linux’s dmem cgroup approach is distinct because it makes device-memory accounting, limits, and protection part of the cgroup framework. Windows’ documented residency and priority interfaces operate in the WDDM and Direct3D environment. Driver behavior, application integration, default policy, and failure modes can all differ.
Still, the underlying physical challenge is shared. When local VRAM is exhausted, neither operating system can make fixed-capacity hardware behave as if it has unlimited GPU-local memory. Both must manage residency, eviction, fallback, or allocation failure in some fashion.
It is also not possible, from the available evidence, to determine what a specific older Radeon’s Windows driver did or did not implement. AMD says some older Radeon generations are under a legacy-support model and will not receive further driver updates. That is useful context for owners of old hardware, but it does not prove that a named—or unnamed—model lacked a particular residency feature or behavior. Resolving that would require the exact GPU, Windows version, driver version, and application API path.
What users can reasonably expect
For Linux gaming PCs, handhelds, and compact living-room machines with constrained VRAM, the most plausible upside is more controlled behavior when workloads compete. A game might contend with a compositor, browser, recording tool, or another GPU-using application. If future user-space tools place these workloads into appropriate cgroups and apply sensible dmem settings, the system could better express which workload deserves protection.
That policy always has a trade-off. Protecting one workload more aggressively can mean another is more likely to lose residency, face limits, or suffer degraded behavior. This is allocation of a scarce resource, not free performance.
Users considering a newer kernel should also avoid assuming that the version number alone activates a complete feature. The merged dmem cgroup support needs to remain present through the eventual release, work with the relevant kernel and driver configuration, and be used by software that establishes a policy. A distribution shipping a newer kernel does not automatically mean that every game receives favorable device-memory treatment.
For an older GPU, reducing VRAM demand remains the most direct intervention. Texture-quality settings, render resolution, and other memory-heavy options can lower the amount of local memory a game needs. That cannot solve every problem, but it attacks the capacity mismatch rather than trying to manage its consequences more elegantly.
Useful testing is equally practical. Reproduce the same game area or application workload using identical settings, and note whether the issue occurs at loading, during scene changes, after alt-tabbing, or only during prolonged play. Distinguish a crash from stutter and from a general performance limit. Without that baseline, a better or worse run can be mistaken for the effect of a kernel update.
Linux’s 7.3 development tree contains a real, merged low-VRAM DRM building block in dmem cgroup eviction support. It may eventually help compatible systems apply better device-memory policy under pressure. The separate TTM and drm_exec work is an interesting proposal aimed at making a contested eviction path more robust, but its inclusion in Linux 7.3 is not established. Neither development abolishes VRAM scarcity, and neither yet proves a benefit for a particular older Radeon GPU. The promising outcome is better management of contention—not a substitute for physical memory capacity or careful testing.