Linux 7.3 is in its final stretch ahead of its official release on October 18, local time. In the Linux 7.3-rc7 announcement, Linus Torvalds, who leads Linux development, said he plans to publish the stable release the following weekend if no new problems turn up. As of October 17, it is still a release candidate. This update adds a mechanism for handling small SSD read requests more efficiently, and another for improving how GPU memory (VRAM) is allocated when several applications, such as games, compete for it. Alongside support for new hardware, many of the changes focus on getting more out of existing equipment, though the effects vary with application workloads and system configuration.
Faster small I/O, cutting CPU overhead rather than SSD limits
With fast SSDs, the bottleneck is sometimes not the storage itself but the CPU load of processing read and write requests. Fengnan Chang of ByteDance measured 4KiB random reads on a PCIe Gen5 NVMe SSD. When accessing the storage directly, he saw about 3.2 million IOPS, but reading files on ext4 or XFS reached only about 1.92 million IOPS. IOPS is a metric for the number of I/O requests that can be processed per second. Analyzing ext4's internal processing, he found that a large share of CPU time went to memory allocation and to repetitive work in "iomap," the common mechanism for managing regions within files and their I/O.
To address this, Linux 7.3 adds a fast path dedicated to small direct I/O. Direct I/O reads and writes storage without going through the kernel's page cache. In the patch that was adopted, the I/O request and its management information are allocated together in memory, and post-processing on successful completion is simplified. In a polling test Chang ran on a single CPU core, ext4 read performance rose from about 1.92 million IOPS to about 2.19 million IOPS.
However, the fast path applies only to I/O requests that meet certain conditions, such as reads that fit within a single filesystem block. Encrypted files and requests that need a bounce buffer are excluded. As a result, not every storage operation, such as writes or large file transfers, gets faster by the same proportion.
In another 4KiB direct-read test by Chang, the improvement for io_uring with polling ranged from −0.06% to 0.54% at QD1 and from 9.76% to 10.06% at QD256. QD (Queue Depth) is the number of I/O requests issued concurrently. The results are below.
| Filesystem | Queue depth (QD) | IOPS before | IOPS after | Improvement |
|---|---|---|---|---|
| ext4 | 1 | 19,283 | 19,272 | −0.06% |
| XFS | 1 | 19,211 | 19,315 | 0.54% |
| ext4 | 256 | 1,663,498 | 1,830,842 | 10.06% |
| XFS | 256 | 1,587,339 | 1,742,220 | 9.76% |
This table extracts QD1 and QD256 results for the same read method from the fio benchmarks Chang included in the commit description. io_uring is Linux's asynchronous I/O mechanism, and this test used polling, which repeatedly checks for I/O completion. The range of improvement reflects differences between the ext4 and XFS measurements, not measurement error. The methodology also differs from the 1.92-million-to-2.19-million IOPS improvement mentioned earlier, so the two cannot be treated as results under the same conditions.
The results show almost no change when requests are handled one at a time, but an improvement of about 10% when many requests are issued in parallel. In other words, the benefit depends not only on SSD performance but on how much I/O the application runs in parallel. In real applications such as databases, request size, queue depth and interaction with other processing also matter, so these results cannot be taken as a system-wide speedup.
Btrfs improves direct I/O and sync, with about a 5x gain under specific conditions
Btrfs also gets changes that make direct I/O more efficient, but the problem they address differs from the small-read issue on ext4 and XFS. Previously, Btrfs had a code path that, to preserve data integrity, switched from direct I/O to buffered I/O, which uses the page cache. Linux 7.3 introduces a way to avoid this fallback by using iomap's bounce buffer. The Btrfs direct I/O improvement and the small-read fast path described above should therefore be understood as separate changes.
Btrfs also gets improvements that cut unnecessary waiting and searching when syncing data to storage. According to David Sterba's description of the update, an extra wait equivalent to one timer tick, which occurred when multiple tasks ran log processing in non-SSD mode, has been eliminated. As a result, throughput in the example workload rose roughly fivefold.
Another change makes fsync, which flushes file modifications to storage, more efficient. Specifically, for files that have no holes (regions without data) and whose storage is split across many extents, unnecessary hole detection is skipped during a full fsync. In the example conditions, this cut processing time to about one-fifth of the previous level. Both are large improvements, but the former reduces waiting time in a specific mode and the latter skips a search for files in a particular state. Neither means that Btrfs reads and writes in general are about five times faster.
Actual results depend on how often an application performs sync operations and how files are laid out on storage. The update also changes a recovery-related mount option: using rescue=usebackuproot now requires a read-only mount, and the standalone usebackuproot option has been removed. Anyone running Btrfs should check their recovery procedures for failures as well as performance.
Better VRAM allocation makes it easier to secure GPU memory for games
Linux 7.3 also improves memory allocation when multiple applications use a GPU's VRAM. Under the previous mechanism, even if an application was meant to get priority for VRAM, it might fail to secure the space it needed if another application had already used it all. Natalie Vock, who works on Linux graphics at Valve, tackled the problem of protected applications being at a disadvantage in such situations.
Linux has cgroups, which manage resources for groups of processes, and the dmem controller, which manages device memory such as GPU memory. According to Vock's patch description, however, when an unprotected application used up VRAM first, TTM, the common memory management mechanism, also redirected new allocations by protected applications to GTT. GTT refers to the region of system memory that the GPU can access. The existing protection mechanism could stop data already in VRAM from being evicted, but could not free VRAM for new allocations.
In the change merged into Linux 7.3, when a protected allocation fails, unprotected buffers are evicted to another memory region to make room in VRAM. This means an application that used VRAM first is not necessarily favored; memory is allocated according to the configured protection policy. The change also prevents unprotected applications from taking VRAM back from protected ones, reducing repeated cycles of eviction and relocation.
That said, this change does not increase the GPU's physical VRAM. It improves how limited VRAM is prioritized among applications. The dmem controller's management interface provides dmem.min, dmem.low and dmem.max for setting per-region protection and limits. Prioritizing a game also requires user-space tooling that makes use of these settings.
The DRM subsystem update also includes dmem eviction support for the AMDGPU and Intel Xe drivers. In other words, the benefit comes only from combining the kernel's memory management with a supporting GPU driver and protection settings. Simply updating to Linux 7.3 will not automatically give the game you are playing top priority.
Valve's contributions extend to older AMD GPUs and input devices
Valve's involvement goes beyond VRAM management. For older AMD GPUs, support for DRM format modifiers is being added to the GFX6 through GFX8 architectures. A DRM format modifier is information that tells components responsible for rendering and display how an image buffer is laid out in memory. DRM maintainer Dave Airlie presented the change as a way to let older GPUs use various Wayland features. Work by Valve's Timur Kristóf and others also helps keep older hardware usable in modern Linux desktop environments.
The same update includes a revision and enabling of software reset handling for GFX8. This concerns recovery when a problem occurs on the GPU and has a different purpose from the DRM format modifier support. Both improve usability and compatibility for older GPUs, but neither raises the GPUs' raw compute performance.
On the input side, the HID subsystem update includes initial support for the 2026 Steam Controller and support for the MSI Claw. Laying the groundwork for the kernel to recognize and handle new input devices matters for widening the choice of Linux-based gaming hardware. However, initial support does not guarantee that Steam Input configuration and controls in every game will work without problems. Real-world feel and feature support still need to be tested.
Apple M3 series and Intel Nova Lake are supported, at different stages of readiness
For new hardware, initial device trees are being added for the Apple M3 Pro, M3 Max and M3 Ultra. A device tree is information that tells the OS about a hardware configuration, such as the CPU and peripherals. According to Sven Peter's explanation, the additions cover basic configuration such as CPU cores, the interrupt controller and power states, and include the framebuffer used for display at boot.
However, adding the initial device trees does not mean every Linux feature now works on M3-equipped Macs. Being able to display a screen at boot is a separate stage from running a desktop environment smoothly with GPU acceleration. This change is a foundation for continuing M3-series support, but it is too early to say a daily-use environment is complete.
Meanwhile, the Xe graphics driver for Intel's Nova Lake-S no longer needs force_probe, which explicitly allows experimental operation. This enables by default hardware support that has been under development and validation. Unlike the Apple M3 series, where initial hardware information is just being added, Nova Lake-S has moved on to making existing support part of normal operation. Even among new hardware, progress toward practical use differs.
When evaluating the improvements in Linux 7.3, it is important to understand the purpose of each change and the conditions under which it applies. In storage-heavy environments, performance should be measured with consistent I/O request sizes and parallelism, and in gaming setups, VRAM protection settings and actual eviction behavior should be checked. For new hardware, it is necessary to distinguish between simply booting and having the needed peripheral functions available. This update shows that even existing hardware can gain performance and usability through more efficient processing paths and better resource management.