Linux 7.3 ships with 18,765 non-merge commits, VRAM and sandbox changes
Linux 7.3 released October 18 with 18,765 non-merge commits. Low-VRAM AMD GPUs get smarter eviction, VM hosts get working-set tracking; games need extra tools.

The Linux 7.3 release shipped on Sunday, October 18, when Linus Torvalds tagged the new stable kernel. LWN counts 18,765 non-merge commits from 3,021 developers, and 807 of those developers were first-time kernel contributors. Gamers on low-VRAM AMD cards are the first audience for the memory work. VM hosts and container operators should look at working-set tracking, idmapped OverlayFS mounts and failfs, a new sandboxing primitive.
Key points
- Scale: LWN counts 18,765 non-merge commits from 3,021 developers, with 807 first-time kernel contributors. Linuxiac calls all three figures records, but neither outlet gives the previous release’s numbers for comparison.
- VRAM: On low-end AMD GPUs, the dmem cgroup can now evict unprotected buffers to make room for protected ones, instead of pushing the protected application into system memory (GTT). Natalie Vock, whom outlets identify as a Valve engineer, wrote the series. The author’s 19.6 ms test (9 GiB requested on an 8 GiB card) came after a drm_exec-based TTM fix that had not reached mainline when the blog was posted. We could not find that fix in either KernelNewbies’ 7.3 list or the torvalds/linux mirror.
- Sandboxing and VMs: failfs and the new fchroot() system call let a process move into a filesystem where absolute path lookups fail. userfaultfd gains a read-write protection mode that lets VM memory managers track guest working sets.
Background
The release arrives about two months after Linux 7.2, according to It’s FOSS. The VRAM work has a longer history. Natalie Vock’s blog post from August 17 says the earlier patch set, from the previous post, was merged upstream and queued for 7.3. The post also explains why running out of VRAM hurts: when the driver has to move data into system RAM, the GPU reaches that memory over PCIe, which is far slower than local VRAM.
Hardware support picked up a small but concrete addition too. The new amd_halo_led driver lets Linux control the lights on AMD’s Ryzen AI Halo mini PC. It’s FOSS reports that, before this, LED control worked only through AMD’s Debian-based Ryzen AI Developer Platform. We covered the Ryzen AI Halo launch earlier.
The facts
The table keeps the changes that matter most to working users. Each row comes from KernelNewbies’ 7.3 changelog, which links to the patches behind it.
| Area | Change | Source |
|---|---|---|
| VRAM | dmem cgroup can evict unprotected buffers to free space for protected ones | KernelNewbies |
| Scheduling | cgroup scheduling adds cgroup_mode; the default concur is the most precise and the most expensive | KernelNewbies |
| BPF | sched_ext sub-schedulers are complete, so each cgroup can run its own BPF scheduler | KernelNewbies, LWN |
| Sandboxing | failfs and fchroot(); entry only through FD_FAILFS_ROOT | KernelNewbies, kernel docs |
| Containers | OverlayFS supports idmapped mounts, easing file ownership management in containers | KernelNewbies, Linuxiac |
| Virtual machines | userfaultfd RWP mode tracks guest memory working sets | KernelNewbies, kernel docs |
| Storage | a small direct I/O path lifts an ext4 sample workload from 1.92M to 2.19M IOPS | KernelNewbies |
| Memory | rmap_walk_ksm optimization cuts worst-case anon_vma lock hold time from over 500 ms to under 2 ms | KernelNewbies |
| Filesystems | ntfs3 gains alternate data streams; ksmbd adds Apple Time Machine support | KernelNewbies |
We checked several of the linked commits against the torvalds/linux mirror on GitHub. Natalie Vock wrote the dmem series, Christian Brauner wrote failfs and fchroot(), Fengnan Chang wrote the small direct I/O path, Wenchao Hao wrote the zsmalloc commit, and xu xin wrote the KSM rmap work. Commit metadata says who wrote each change, not which company employed them, so the employer claims in some coverage (Valve, ByteDance, ZTE, Xiaomi) are not confirmed by primary material. The v7.3 tag is signed by Linus Torvalds and dated 23:14:58 UTC on October 18. That is 13:14 at UTC-10, and 07:14 on October 19 in Beijing.
What others say
GamingOnLinux is the most measured voice. It says Valve-funded changes may reduce stutter and frame drops, but the full benefit needs userspace tools such as dmemcg-booster and plasma-foreground-booster, plus compatible drivers. Upgrading alone will not enable everything. Its closing line: “As always, don’t expect a magical performance boost across every game.”
OMG! Ubuntu offers a concrete example. Indiana Jones and the Great Circle stayed playable on an 8 GB card with memory demand pushed toward 9 GB. It’s FOSS adds that this is the effect of the full patch set, and the rest of that set is still on its way to Linux. It also relays a cgroup scheduling test by Peter Zijlstra: one game’s minimum frame rate rose from 3.8 fps to 20.6 fps with eight heavy background processes, and its average rose from 48 fps to 57.2 fps. Only OMG! Ubuntu reports those numbers, and we could not verify them in primary material.
It’s FOSS reports two patch results. A ZTE fix for a KSM lock problem cut the worst case in a stress test from 705 ms to under 2 ms. A Xiaomi zsmalloc change reached up to 1.83x on a Raspberry Pi 4B, and 1.4x on a 20-core Intel system. KernelNewbies gives the 1.83x figure without naming a test platform. These results belong to individual patches and say nothing about the whole release. The Chinese report from cnBeta makes a similar point about its Btrfs coverage: real gains depend on hardware, filesystem settings and workload.
On Hacker News, the LWN release thread had 233 points when we checked on October 19. The sharpest comment came from rwmj, who argued that the kernel handed users a set of system calls with no design consistency, which must be used very carefully or they can be bypassed. The comment pointed to the caveats listed in the failfs documentation. Another commenter read failfs as a finer-grained chroot.
The August VRAM post drew 547 points and 313 comments on Hacker News. One top-level comment asked whether any of this helps local LLM inference. It is a fair question, but none of the 7.3 material we read includes a test of an inference workload.
Our take
For VM hosts, RWP is the most useful change in this release. It gives the memory manager a working-set signal, which is what it needs to decide what moves to tiered or remote storage. The kernel supplies the mechanism. The policy is still yours to write.
For sandbox authors, failfs is an interesting building block. Once inside, absolute and working-directory lookups fail, so a process has to hold every resource it needs as an open file descriptor before it enters. For a program designed that way, the model is clean. For older software that depends on paths, it means changing access patterns first. Most users will never call it directly.
For gamers, the 7.3 VRAM change is merged, and KernelNewbies and Linuxiac both list it. The only VRAM benchmark we found covers the full patch set, including a TTM fix we could not confirm in 7.3, and it covers one game, one set of settings and one machine. The author’s own numbers show that frame-time spikes above 33.3 ms appear often at 10 GiB of demand, with an average near 29.8 ms. That matches GamingOnLinux’s caution: the gain depends on the game, and a kernel upgrade alone does not deliver it.
The 18,765 commits measure development activity. They tell us how large the contributor base is, and they say little about whether 7.3 runs better than 7.2.
What to watch
The 7.4 merge window opened on October 19. LWN quotes the Linux 7.3 announcement, which says a family vacation will make the merge schedule unusual for a while, so expect irregular merges for a bit.
GamingOnLinux and OMG! Ubuntu both say more VRAM work is coming in later kernels. The blog, dated August 17, says the drm_exec-based TTM fix still needed more work before it could be merged, so the full VRAM picture depends on later releases. The page-cache read-path series posted on October 13 (our report on Linus’s kernel patch) is not part of 7.3. On the normal schedule it could not have made this release, so whether it lands in 7.4 depends on that merge window.