Kernel patches behind a Mesa/RADV developer's VRAM management work are merged and queued for Linux 7.3, changing what happens when a game, or a local LLM run, asks an AMD GPU for more VRAM than it has. The newest work traces the worst crashes to a lock ordering deadlock in the kernel's shared memory manager, not the memory system itself, and shows the underlying performance hit is often survivable.

  • Patches from the author's earlier VRAM management work are merged upstream and queued for Linux 7.3.
  • The crash traced to a wound/wait deadlock: TTM, the memory manager shared across Linux GPU drivers, mostly skips the retry helper drm_exec, so a submission that hits a deadlock gets rejected instead of retried.
  • A rebased fix wiring drm_exec into TTM isn't merged yet; the author called its remaining bugs "one week of intense suffering."
  • On PCIe 4.0 x16, a GPU can pull about 1 GiB per 33.3 ms frame before 30 FPS is impossible, but cache-friendly allocations evict for nearly nothing.

What actually landed in Linux 7.3

The news is narrow: patches from an earlier body of VRAM management work by a Mesa/RADV and kernel developer are merged and queued for 7.3. The question they set out to test is blunt: what happens when a game asks for more VRAM than the GPU has? Conventional wisdom says crashes. In theory it shouldn't. Drivers have supported overcommit for as long as they've existed; an evicted buffer moves to CPU RAM and gets fetched over PCIe on the next access, like any cache miss.

Related'You're the OS' Turns Kernel Scheduling Into a Game

Why did running out of VRAM crash instead of just slowing down?

Under real pressure, RADV started printing "radv/amdgpu: Not enough memory for command submission," and the kernel returned -ENOMEM at submission time, not allocation time, though every buffer involved was already allocated. The cause is bindless APIs: every submission must make all potentially-referenced memory accessible, and some must live in VRAM. Bringing evicted memory back means evicting something else, which takes a lock, and two submissions doing that at once is a textbook deadlock. The kernel has a fix for this, wound/wait transactions: a wounded transaction's next lock attempt returns -EDEADLCK on purpose and is meant to retry cleanly. The drm_exec helper wraps that retry loop, but TTM, the memory manager shared across Linux GPU drivers, mostly doesn't use it, and its own source even notes -EDEADLCK will make eviction fail. So the kernel just rejects the submission, and that rejection is the crash.

Patches to wire drm_exec into TTM were sent as far back as 2024 and never landed, over unresolved bugs. The author rebased the patchset and spent, in their words, a week of intense suffering tracking down games that hung for three minutes under heavy contention. A fix has been resent but still needs work before it merges, so that isn't what lands in 7.3; what's queued is the earlier groundwork plus the throttling and priority work below.

What does the scanout buffer have to do with it?

Fixing the deadlock removed one failure mode, not all of them. gpuvis tracing found a second: most time under pressure went not to submission but to sdma0, the memory-moving engine, as gamescope and the game traded the same buffer back and forth. dmem cgroup VRAM protection, meant to shield one app's memory from another, made that worse, because it can't protect the one thing that must stay in VRAM regardless: the scanout buffer, which display hardware reads at a physical address, bypassing the GPU's virtual memory. A scanout image needs one contiguous block, unlike ordinary buffers, which are only contiguous virtually and get scattered as VRAM fills. Eviction ignores that, freeing the least-recently-used buffer in a loop, so freeing three neighbouring buffers can still leave no gap big enough. The author watched the kernel nuke up to 4 GiB of VRAM to fit a 32 MiB scanout image; moving that 4 GiB back out costs at least around 130 ms, several dropped frames at once.

Eviction path from VRAM to CPU RAM, and the scanout contiguity problemA GPU evicting a buffer to CPU RAM over PCIe, plus a fragmented VRAM free-space bar where no gap fits a 32 MiB contiguous scanout block. MEMORY PATH Eviction under VRAM pressure GPU Infinity Cache VRAM 8 GiB resident CPU RAM evicted PCIe 4.0 x16 ~32 GiB/s evict fetch on access VRAM free space, fragmented 32 MiB scanout needs 1 block no single free gap is wide enough alone genztech.blog
Fig 1 Evicted buffers move to CPU RAM over PCIe. A scanout image needs one contiguous block, which fragmented free space may lack even with gigabytes free.

The fix has two parts: a throttling heuristic that briefly stops moving an evicted app's memory back in, then restricts eviction to that app's own memory for a few seconds, plus letting apps rank buffers by evictability via the Vulkan extension VK_EXT_pageable_device_local_memory. The kernel's LRU list used to move a touched app's buffers to the end in bulk, undefined order; now it sorts them by priority, least important first.

How much does eviction actually cost in frames?

The author measured this with Indiana Jones: The Great Circle on an 8 GiB card, whose streaming pool setting maps almost directly to VRAM demand. Requesting 9 GiB, 1 GiB over, averaged 19.6 ms per frame, called perfectly playable. Requesting 10 GiB, 2 GiB over, averaged about 29.8 ms, with spikes past the 33.3 ms, 30 FPS mark frequent enough to notice.

RelatedWindows 11's Weather App Is Eating Over 1 GB of RAM

Measured frametime at 1 GiB and 2 GiB VRAM overcommitBar chart of average frametime on an 8 GiB card. 1 GiB overcommit averages 19.6 ms. 2 GiB overcommit averages 29.8 ms. A dashed line marks the 33.3 ms threshold for 30 FPS. BENCHMARK Frametime under overcommit 8 GiB card, Indiana Jones: The Great Circle 33.3 ms · 30 FPS floor 19.6 ms 1 GiB overcommit 29.8 ms 2 GiB overcommit ms genztech.blog
Fig 2 · benchmark 1 GiB of overcommit stays well under the 30 FPS floor. 2 GiB of overcommit averages under the floor too, but spikes past it often enough to feel it.

Honoring memory priorities instead of random eviction improved performance by up to 30% in the author's best case, a number they say deserves a mountain of salt since it depends almost entirely on which buffers get evicted.

Who actually benefits first?

Adoption isn't universal. The author hasn't seen an idTech game use the priority extension directly. D3D12 fares better by accident: vkd3d-proton, which runs Direct3D 12 games on Vulkan, already translates MakeResident, Evict, and SetResidencyPriority into Vulkan priorities, so games calling those APIs get the benefit for free.

  1. 2024First deadlock-fix attempt stalls drm_exec-in-TTM patches sent, blocked on unresolved bugs.
  2. EarlierVRAM management groundwork The author's prior work becomes the basis for 7.3.
  3. MergedThrottling and priority patches land Hard/soft throttle and LRU priority ordering queued for 7.3.
  4. Aug 17, 2026Writeup published pixelcluster's "VRAM Management Part 2" details the mechanism.
  5. Nextdrm_exec in TTM, still pending A rebased fix is resent but needs more work to merge.
What to watch · Linux 7.3 and after
  • The drm_exec merge. The real crash fix isn't in 7.3; watch whether the rebased patchset lands.
  • Priority extension adoption. Direct calls remain rare outside the vkd3d-proton path.
  • Variance, not averages. The 29.8 ms average hides frequent spikes, which is what a player feels.
  • Non-gaming workloads. The same eviction path governs local inference too, unbenchmarked so far.

Our take

This reads like a graphics driver story, and it is one, but the mechanism applies to anything streaming big buffers across PCIe under memory pressure. An 8 GiB card running local LLM inference hits the same ceiling: weights that don't fit get pushed to CPU RAM, bound by the same rough 32 MiB per millisecond, and a careless eviction path stalls inference for the same reason a game's frametime spikes. This is general-purpose memory pressure handling, not gaming plumbing, and that audience is growing faster than the game market. A workload already tight on latency gets no margin back once eviction starts.

Primary sources

Original analysis by GenZTech. Source: pixelcluster's GPU blog