Linux 7.3 could be one of the most performance-focused kernel releases in years

Linux 7.3 is still under development, but the improvements landing during its merge window point to a particularly interesting release for storage, latency, memory management and hybrid processors. Btrfs, EXT4, the CPU scheduler, zsmalloc, KSM and SMP code are all receiving changes that, in specific workloads, deliver improvements ranging from around 10% to several times the previous performance, although benchmark results should not be confused with the gains every user will see once the stable release arrives.

Linux 7.3 highlights in 20 seconds

• Btrfs improves direct I/O and moves toward free-space cache v2 as the default.
• EXT4 and XFS gain performance for small direct I/O operations on PCIe 5.0 SSDs.
• Scheduler changes aim to reduce latency and improve frame pacing under load.
• zsmalloc and KSM reduce lock contention that can particularly affect systems under heavy memory pressure.
• Intel is improving workload distribution between P-cores, E-cores and low-power cores.

Linux 7.2 was released on August 16, 2026, and Linus Torvalds immediately opened the merge window for Linux 7.3. Many of the features currently being discussed are therefore already proposed or being merged, but the stable release is not yet available, and some changes could still be modified or even reverted if regressions emerge during the release candidate cycle.

Even with that caveat, the overall direction is fairly clear. Linux 7.3 does not appear to be dominated by one spectacular new feature. Instead, it focuses heavily on removing bottlenecks that are becoming increasingly visible with very fast storage, high core counts and workloads that are particularly sensitive to latency.

Btrfs improves precisely where its complexity has traditionally hurt performance

Btrfs accounts for some of the most interesting performance work in this development cycle.

One area involves O_DIRECT operations. Since Linux 6.14, Btrfs could cause certain direct writes with checksums to fall back to buffered I/O to avoid inconsistencies if an application modified the buffer while its checksum was being calculated.

Linux 7.3 introduces a bounce buffer for these situations. According to the official Btrfs documentation, this mechanism can achieve roughly 95% of the performance of truly zero-copy direct I/O, without falling back to the buffered I/O path.

The update also changes the internal management of extent buffers and removes unnecessary waits in some concurrent logging scenarios.

Performance improvements of 3x to 5x have been reported in some Btrfs benchmarks, but those numbers should not be interpreted as Linux 7.3 making every Btrfs filesystem five times faster.

These results apply to specific code paths and workloads. The actual improvement experienced by a user will depend on the operations being performed, storage device, concurrency, configuration and filesystem size.

Another important change involves the free-space cache.

Btrfs has long provided two implementations: space_cache=v1 and free-space tree, or v2. The former has historically been the default, while v2 uses an additional B-tree to track available space and scales better on large filesystems. Documentation has already warned that v1 can suffer substantial performance degradation on multi-terabyte volumes and under certain workloads.

Work targeting Linux 7.3 moves away from v1 as the default choice in favor of space cache v2, although existing installations need to take the current state of their filesystems into account.

For servers, NAS systems and workstations using large Btrfs volumes, this could be one of the most relevant changes in the entire release.

EXT4 and XFS are facing an unexpected problem: the kernel can be slower than the NVMe

Modern storage helps explain exactly why these optimizations are becoming necessary.

In one test involving random 4 KB reads on a PCIe Gen5 NVMe SSD, the raw block device reached around 3.2 million IOPS using io_uring in polling mode.

Running essentially the same workload through EXT4 or XFS reduced performance to approximately 1.92 million IOPS.

The main bottleneck was no longer the SSD.

It was software overhead.

Analysis showed substantial CPU time being consumed by __iomap_dio_rw(), the iomap iterator, memory allocations and operations associated with I/O completion.

The solution prepared for Linux 7.3 introduces a simplified path for small direct I/O operations when certain conditions are met.

Published results show EXT4 increasing from 1.92 million to 2.19 million IOPS in the original benchmark, an improvement of roughly 14%. Tests with fio showed gains of around 4% with libaio, approximately 5% with io_uring, and as much as 10% with io_uring polling at high queue depths, across both EXT4 and XFS.

This is a good example of how kernel optimization is changing.

For years, much of the work focused on hiding the enormous latency of mechanical hard drives. With a latest-generation NVMe SSD, a few microseconds of software overhead can become the bottleneck instead.

EXT4 is also receiving additional work around its multi-block allocator and fallocate() paths, although those changes should not be conflated with the jump from 1.92 million to 2.19 million IOPS. That specific result comes from the simplified iomap path for small direct reads.

The scheduler changes to reduce stuttering under load

Another particularly interesting area is the CPU scheduler.

A patch series known as “flatten the pick” changes how EEVDF behaves when cgroup hierarchies are involved.

The issue is that intermediate structures used to represent task groups can temporarily hide which processes are actually eligible to run. This can increase scheduling overhead and latency.

The new approach preserves the cgroup hierarchy while using a flatter EEVDF queue to select tasks.

Tests carried out during development used a relatively old system with an Intel Sandy Bridge processor and AMD Radeon Polaris GPU, specifically to examine scenarios where every additional millisecond can become visible.

The results point to higher FPS and, more importantly, more consistent frame times when the system is under cgroup-related load.

This is where references to improvements on “potato-class” hardware come from.

It does not mean Linux 7.3 will dramatically increase frame rates on every old computer. The effect is more specific: when competing workloads and scheduler overhead cause delays, reducing that interference can improve frame-time spikes.

For gaming, that distinction matters.

A system can maintain an average of 60 FPS and still feel unpleasant if individual frames occasionally take much longer to render. Improving consistency can therefore be more noticeable than slightly increasing the average frame rate.

zsmalloc delivers up to 1.83x gains on Raspberry Pi under concurrency

Memory management is also receiving some very targeted optimizations.

zsmalloc is a memory allocator used particularly by compressed-memory technologies such as zram.

A set of changes aims to eliminate contention inside zs_free(). On 64-bit systems, the class index can be encoded directly into the object value, avoiding the need to acquire certain global locks to determine its class.

The results are particularly interesting on small hardware.

On a Raspberry Pi 4B with four Cortex-A72 cores, a concurrent test using four processes dropped from 202.9 ms to 110.6 ms, equivalent to approximately 1.83x the performance.

With two processes, the gain was 1.42x.

On an x86 system using an Intel Core i7-12700 and 16 concurrent processes, improvements were around 1.39x to 1.40x for those multithreaded workloads.

The difference with a single process was much smaller.

That helps put the numbers into perspective: the optimization primarily targets contention between processes, so its impact increases when multiple CPU cores attempt to free compressed memory simultaneously.

For systems that make intensive use of zram, including small ARM devices, the improvement could be particularly useful.

KSM reduces lock times from more than half a second to under 2 ms

Another memory-management change comes with even more dramatic figures.

Kernel Same-page Merging (KSM) identifies memory pages containing identical data and allows them to be shared. The technology is especially useful in virtualization and environments running many similar workloads.

The problem appeared during certain reverse mapping operations.

In a test involving 20,000 VMAs sharing the same anon_vma, an inefficient KSM path could hold a lock for more than 500 ms.

Figures published by the developers show a worst-case result of 705 ms before the change and 1.67 ms afterwards, with a measured maximum average of 1.44 ms.

That represents an improvement of several hundred times in that particular scenario.

The important point is not KSM alone.

The same lock may also be required for page faults, memory reclaim, migration, compaction, mlock, process termination and cgroup accounting.

Holding it for hundreds of milliseconds can create latency spikes, reduce throughput and even cause timeouts in containers.

The Linux 7.3 improvement is therefore less about increasing a benchmark score and more about eliminating extremely long pauses in pathological but possible scenarios.

SMP P99 latency drops from around 17 ms to 1.5 ms

Another of the most interesting server-oriented optimizations involves SMP code.

Some cross-processor calls use IPIs, or Inter-Processor Interrupts, to ask other CPU cores to execute an operation.

Until now, some functions kept preemption disabled while waiting for all remote processors to complete their work.

If one CPU took too long to respond, this could produce a substantial latency spike.

Engineers at ByteDance worked on allowing preemption again during this waiting period.

According to data associated with the change, P99 latency for high-priority tasks measured in production fell from approximately 17 ms to 1.5 ms, a reduction of around 90%.

Latency-sensitive workloads such as DPDK could particularly benefit.

It is also relevant for large servers where operations involving TLB handling, memory release or process termination can trigger numerous cross-CPU calls.

Again, this does not mean every application suddenly becomes ten times faster. The improvement specifically reduces long-tail latency when this SMP waiting pattern occurs.

Alder Lake, Lunar Lake and Panther Lake improve workload distribution

Intel’s hybrid architectures continue to present interesting challenges for Linux.

Modern processors can combine performance-oriented P-cores, efficient E-cores and even very low-power cores, leaving the scheduler to constantly decide where each task should run.

Linux has supported cluster-aware scheduling since 2021 to group cores sharing caches or other intermediate resources.

The problem is that this approach does not always map cleanly onto hybrid CPU designs.

Intel has prepared changes for Linux 7.3 aimed at improving this cluster-aware load balancing, particularly when the system is running mixed workloads and new tasks arrive while other cores are already busy.

The changes are relevant to processor families including Alder Lake, Lunar Lake and newer Panther Lake designs, although their real-world impact will need to be measured once Linux 7.3 gets closer to its final release.

Large differences should not necessarily be expected in purely single-threaded benchmarks or workloads capable of fully saturating every core. The potential benefit is more likely to appear in mixed workloads, which are much closer to how a real desktop or laptop is actually used.

Linux 7.3 looks designed to remove bottlenecks that did not matter before

There is a common thread running through many of these changes.

Hardware is forcing the kernel to eliminate overhead that would have seemed relatively insignificant only a few years ago.

A PCIe 5.0 NVMe SSD can expose a generic software layer as the bottleneck at millions of IOPS.

Dozens of CPU cores can make keeping preemption disabled while waiting for an IPI a latency problem.

Compressed memory works well until many processors start competing for the same lock.

Hybrid CPUs perform correctly until the scheduler has to choose between cores with substantially different performance and power characteristics.

The same phenomenon appears in Btrfs, where data structures designed years ago increasingly need refinement as filesystem sizes and workloads continue to grow.

Linux 7.3 is still going through its development cycle, so release candidates and independent benchmarks will be needed before drawing firm conclusions about how much faster individual desktops and servers will become.

But judging by the work currently landing, Linux 7.3 is shaping up to be a release heavily focused on reducing latency, improving concurrency and extracting more performance from modern hardware without requiring applications to change.

Frequently asked questions

Is Linux 7.3 already available?

Not as a stable release. Linux 7.2 was released on August 16, 2026, after which the Linux 7.3 merge window opened. It still needs to go through the release candidate cycle before its final release.

Will Btrfs really be three to five times faster with Linux 7.3?

Not across all workloads. Improvements of that magnitude have been observed in specific scenarios involving particular internal code paths. Many other operations will see much smaller gains.

What does Linux 7.3 improve for PCIe 5.0 SSDs?

A simplified path for small direct I/O operations reduces iomap overhead. In one EXT4 benchmark, random 4 KB reads using io_uring increased from 1.92 million to 2.19 million IOPS.

Will Linux 7.3 improve gaming performance?

The EEVDF and cgroup scheduler work can reduce latency and improve frame-time consistency when competing workloads are present. Early results are promising, particularly on older hardware, but they do not imply a universal FPS increase for every system.