Linux 7.3 Queues Kernel Work on VRAM Overcommit Stability

Why excess VRAM demand hurts

Kernel patches intended to improve graphics-memory management were merged upstream and queued for Linux 7.3, according to a developer’s technical account dated August 18, 2026. The work focuses on what happens when a game requests more video memory than a graphics card physically contains.

GPU drivers have long allowed VRAM overcommitment. When allocations exceed device memory, some data can be evicted to system RAM. In theory, that should make the workload slower rather than unstable. In practice, the author found that exhausting VRAM could also lead to command-submission failures in the RADV and AMDGPU stack.

The unavoidable performance cost begins with the connection between the GPU and system memory. CPU RAM is slower for a discrete GPU to access, and transfers must cross the PCI Express bus. A PCIe 4.0 x16 link provides slightly less than 32GiB per second, or about 32.2MiB each millisecond. At 30 frames per second, a frame lasts roughly 33.3 milliseconds, putting the theoretical transferable amount near 1,075.5MiB. If a frame needs more than about 1GiB of evicted data, the bus alone makes 30fps unattainable.

That limit does not mean every access to CPU memory ruins performance. Drivers sometimes leave command-related allocations in system RAM even with available VRAM. Caching and access patterns determine the effect. If data remains in a higher-level cache, the location backing it does not change cache-hit latency. Rarely accessed or cache-friendly allocations can therefore be less damaging eviction targets.

Latency and stability are separate problems

Microbenchmarks on an RDNA3 GPU showed the distinction. Once a buffer exceeded the 6MB L2 cache, access to CPU-backed memory rose to about 2,400 cycles. The author estimated PCIe fetches at roughly 7.3 times the latency of an Infinity Cache hit and 4.6 times that of a VRAM fetch. High cache-hit rates are needed to absorb that penalty.

Those measurements explain why overcommit performance is difficult to predict. Evicting several gigabytes is not necessarily catastrophic if only a small part is read in a frame. Conversely, a smaller amount with unfriendly, frequent access can create severe stalls.

The kernel issue went beyond those expected slowdowns. A game could allocate its buffers successfully, then receive an out-of-memory error when submitting already prepared commands. RADV reported that condition when the kernel returned `-ENOMEM`, even though command submission itself was not requesting a new resource.

The queued Linux 7.3 work emerged from investigating that mismatch between successful allocation and failed use. The supplied excerpt does not detail the final patch mechanics or provide game benchmarks, so its supported conclusion is narrower: upstream changes are scheduled, and they target stability behavior that made VRAM pressure worse than bandwidth limitations alone require.