Linux 7.3 graphics: what actually matters if you keep servers four to six years
The Linux 7.3 merge window opened in late August 2026, and the graphics pull is wider than usual. Fixes for AMD cards from 2012 sit in the same tree as enablement for Intel silicon that has not shipped in volume yet. That spread is the part worth your attention if you run hardware on a long refresh cycle. A render node bought in 2022 keeps picking up reset-recovery and display fixes instead of being frozen on whatever driver its distro pinned at install time.
The caveat has to come first, because it decides whether the rest is relevant to you. 7.3 is not released. It is in the merge window, several release candidates away from a tag, and further still from your distribution. If your only question is when you will actually run it, jump to the timeline section below and skip the feature detail.
The short version
| Change in 7.3 | Who it affects | Depends on |
|---|---|---|
| GPU reset recovery improved for older AMD hardware | Anyone running a 4-6 year old render node | Distro backport |
| Xe3P Nova Lake stable, no longer behind force_probe | Future Intel hosts | Shipping hardware |
| DMEMCG eviction (AMDGPU and Intel) | Multi-tenant GPU boxes, eventually | Userspace support |
| Nova (Rust NVIDIA) vGPU enablement | Nobody in production yet | Driver maturity |
| "Flatten the Pick" scheduler rework | Container density, p99 latency | Merged in 7.3 |
What actually landed in the graphics pull
Old AMD hardware got real attention this cycle. DRM format modifier support now extends back to the GFX6 through GFX8 era, meaning Southern Islands through Polaris, so roughly 2012 to 2016 silicon. The change that matters more for anyone running a server is less glamorous: GPU reset recovery for older hardware improved. That fix decides whether a wedged GPU on a shared render node recovers on its own or takes a host reboot with it. When a single stuck job forces a reboot, you do not lose one tenant's work. You lose every job running on that box at the time, plus the ten to twenty minutes of reprovisioning that follows.
On newer AMD parts the pull enables the second graphics pipe on modern APUs, adds DCN 6.0 display core support, DC CACP support, 8K display fixes, and support for some next-generation AMD graphics IP blocks. Intel's Xe3P Nova Lake graphics are now considered stable and enabled by default rather than gated behind the force_probe module parameter. That flag is the line between "a kernel developer can test this by hand" and "a distro kernel binds to it on boot without you touching a config." For a fleet operator, the second state is the only one that counts.
On the NVIDIA side, be careful what you conclude from the changelog. The work here is entirely in the open-source stack. Nouveau gains NVDEC support to enable NVK Vulkan Video, and the Rust-based Nova driver keeps building out with Blackwell and Hopper fixes, GSP boot improvements, and vGPU enablement. This is genuine progress. Nova is not a production inference driver today.
The distinction is bigger than it sounds. If you run an L4, an A10 or an H100 for inference, your card is driven by NVIDIA's own out-of-tree driver, not the in-tree DRM stack. Kernel graphics improvements, in 7.3 or any other release, largely do not touch that path. Any article promising you kernel-driven inference throughput gains on NVIDIA datacentre cards is describing something that does not happen. Your inference performance is a function of the NVIDIA driver version, the CUDA toolkit, and the runtime, and it moves on NVIDIA's release schedule, not the kernel's.
Also in the pull: the Qualcomm MSM driver adds Adreno 704 and 722 support, TTM becomes more aggressive about memory handling, and the Rust DRM infrastructure keeps expanding across the tree.
DMEMCG: the one to watch for multi-tenant GPU hosting
The change with the longest tail is DMEMCG eviction, work led by Natalie Vock at Valve, reported to be initially working for both AMDGPU and Intel graphics in 7.3. The immediate goal is gaming: behave gracefully when a workload exceeds available VRAM instead of falling off a performance cliff. The reason it belongs in a hosting discussion is the mechanism underneath it.
DMEMCG is device memory accounting through cgroups. It is the same control-group machinery that already bounds a tenant's RAM, CPU and I/O, extended to GPU memory, with eviction when a group runs over its share. That is the missing primitive for honest multi-tenant GPU hosting. Today, dividing a single GPU between customers means one of two things. Either full passthrough, where one tenant gets the whole card and you sell it as a unit. Or a vendor vGPU or SR-IOV scheme, each with its own licensing cost and hardware constraints. Per-cgroup device memory limits are a third path that does not require either.
Two pieces of realism keep this honest. "Initially working" means exactly that. This is the first cycle the code exists, not a finished, tuned feature. And a kernel primitive is not a product: container runtimes, schedulers and orchestrators all need to grow support for it before you can carve a GPU into slices and bill for them. Watch this one across the next three or four releases rather than planning a product around it now.
Scheduling: "Flatten the Pick" and sched_ext sub-schedulers
Two scheduler items in 7.3 are worth understanding, and most of the internet gets both of them wrong.
Start with a correction you will see repeated elsewhere. The Linux scheduler is not CFS anymore. CFS was replaced by EEVDF, Earliest Eligible Virtual Deadline First, back in 6.6 in 2023. Any 2026 tuning guide telling you to "stick with CFS" was written from stale notes. This matters here because Michael Larabel reported on 6 July 2026 that 7.3 is expected to "Flatten The Pick," and that patch series is EEVDF work. Intel engineer Peter Zijlstra's approach moves the EEVDF runqueue outside the cgroup hierarchy while leaving the hierarchy itself in place. It preserves the weight approximations that keep scheduling fair, while cutting the latency that intermediate cgroup entries add on every pick. The default cgroup mode becomes concur, with tasks, max, up and switch also available.
The word doing the work in that description is cgroup. Phoronix framed the benefit around gaming, benchmarking a Sandy Bridge system with Radeon Polaris graphics and reporting an FPS gain plus much lower frametime "amid the cgroup noise." Every container on a shared host is a cgroup. Deeply nested hierarchies are the normal state of a container platform, not an edge case you engineer around. A shorter, flatter pick path is a container-density change wearing a gaming benchmark.
Where it plausibly helps on a mixed host: a batch job and a live PHP-FPM pool sharing the same cores, where one tenant's CPU burst currently stalls another tenant's request mid-flight. The metric to watch is p99 request latency under CPU contention, not average throughput. Averages hide this entirely, because the stall lands on a small fraction of requests and the mean absorbs it.
Second, sched_ext. You may read that sched_ext is "arriving" or "being marked ready" in 7.3. It is not new. The extensible scheduler class, CONFIG_SCHED_CLASS_EXT, which lets you load a BPF scheduling policy without recompiling or rebooting into a patched kernel, has been merged and shipping since the 6.11 and 6.12 cycle in late 2024. What is new in 7.3 is that sub-scheduler support is now feature complete. That is meaningful if you are already writing custom policies and irrelevant if you are not.
The honest caveat covers all of it. A latency-first scheduling policy trades against throughput work like backups and video encodes. We have not benchmarked that trade on our own fleet, so we are not going to quote you a number for it. If you run a single-purpose VPS with one workload, the stock scheduler is the right answer and this whole section does not apply to you. Scheduler tuning earns its keep on contended, mixed hosts, and nowhere else.
Where 7.3 sits in the release timeline
| Version | Date / state | Status |
|---|---|---|
| 7.0 | 12 April 2026 | Released |
| 7.1.10 | 23 August 2026 | Current stable on kernel.org |
| 7.2 | 16 August 2026 | Current mainline |
| 7.3 | In merge window | Not released |
For cadence, 7.0 shipped on 12 April 2026 and 7.2 on 16 August 2026, which is roughly nine to ten weeks per release. The jump to 7.0 was not a technical milestone. Torvalds bumped the number because, in his words, he was running out of fingers and toes again.
7.2 is the release you are most likely to meet first. Its highlights were cache-aware scheduling that co-locates tasks sharing a Last Level Cache domain, a fairer GPU scheduler from Igalia modelled on the ideas of the original CFS task scheduler, initial Apple M3 support, USB4STREAM, AMDGPU HDMI 2.1, and initial Intel Xe CRI platform support.
The merge window is where maintainers push their changes to Linus. It is followed by seven or eight weekly release candidates before a final tag, which is roughly two months of stabilisation. So treat any "7.3 has feature X" claim, including this article's, as provisional until the tag actually lands. Features get dropped in rc, and behaviour changes between rc1 and the final release more often than the headlines admit.
When you'll actually run 7.3
Three kernel lines matter for planning, and the gap between them is the whole story.
| Line | What it is | Who should run it |
|---|---|---|
| Mainline (7.3-rc) | Newest code, unvetted | Kernel testers, never production |
| Stable (7.1.10) | Backported fixes, short support | Arch, Fedora, enthusiast distros |
| Longterm (LTS) | Years of security fixes | Debian, Ubuntu LTS, RHEL, most servers |
Fedora or Arch may carry 7.3 within weeks of the tag. The LTS kernels currently maintained on kernel.org are 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10, and that list is what most servers are actually running right now. Concretely: Ubuntu 26.04 LTS shipped with 7.0 in April 2026. RHEL 9 is still on a 5.14-derived kernel, and RHEL 10 ships 6.12. If you are on an enterprise distro, the 7.3 changes described here reach you as selective backports, months to years out, and some will never be backported at all.
Before you plan around any 7.3 feature, run a quick sanity pass on the box you actually care about:
- Check the running kernel with uname -r. If it starts with 5.14 or 6.12, you are on an enterprise line and none of the 7.3 code above is present until your vendor backports it.
- Confirm whether the feature you want is a mainline addition or a backportable fix. Reset-recovery improvements often get backported. New default cgroup scheduler modes usually do not.
- For GPU work, check which driver binds your card with lspci -k. If it names the NVIDIA proprietary module rather than nouveau or nova, the in-tree graphics changes do not affect you at all.
- Decide the line you want to sit on before you chase a feature. An LTS kernel with a two to three year support tail is the correct default for a production host, even when it means waiting on a backport.
The practical takeaway is narrow. The reset-recovery and older-AMD display fixes are the parts of 7.3 that reach a real fleet soonest, through distro backports, and they matter most to operators keeping render nodes past the four year mark. DMEMCG and the flattened EEVDF pick are the ones to track over the next few cycles, not to build against today. And if anyone tells you 7.3 speeds up NVIDIA inference, check uname -r and lspci -k, then ask them which driver they think is doing the work.
