Linux 7.3 is out. The PCIe Gen5 NVMe bottleneck fix is the part worth reading.

Linux 7.3 is out today. The merge window post from September covered the memory management pile and the NTFS3 work. This one is about the release itself, and specifically the performance changes that matter if you run fast storage.

the PCIe Gen5 NVMe fix

Gen5 NVMe drives are fast. The kernel was not keeping up with them on small direct I/O.

The problem was in the IOmap layer. When a small direct I/O request did not align to a block boundary, the code fell back to buffered I/O instead of using a bounce buffer. That fallback cost you most of the drive’s bandwidth on workloads with small, misaligned writes. On a drive that should saturate somewhere near theoretical maximum throughput, you were getting roughly half. Databases do this kind of I/O constantly.

The fix adds an IOmap bounce buffer path. Direct I/O stays direct. Phoronix benchmarks show the workload moving from roughly 50% to roughly 95% of the drive’s rated throughput. That is not a rounding error; that is a real bottleneck that has existed since Gen5 NVMe SSDs showed up and finally got fixed in 7.3.

If you run PostgreSQL or anything that issues O_DIRECT writes on a Gen5 drive, this release is the one to track.

Btrfs numbers

I will state for the record that ZFS is still the correct answer for anyone running storage that matters. The OpenZFS 2.3 post from September covers where that project is. That said, the Btrfs numbers in 7.3 are real and worth noting.

The logging path and the fsync path each pick up roughly 5x gains from separate fixes. The inhibited extent buffer tracking replaced XArray with a local LRU list, which adds roughly 3x on that specific path. These are not the same 5x twice; the logging and fsync patches address different things.

Whether that makes Btrfs good enough for your production storage is a question I will leave to the people running it. The numbers are the numbers.

EXT4 parallel direct I/O

EXT4 was refusing to issue parallel direct I/O writes in situations where it could safely do so. The code was checking whether it needed an exclusive lock and then taking one anyway when the check was ambiguous.

7.3 fixes that. Parallel direct I/O writes now proceed where the exclusive lock is not actually required.

This is the kind of thing that gets described in a commit message as “too conservative” and then lives in the codebase for years before somebody measures it. EXT4 is not going anywhere. It is still the default on most Linux systems and probably the filesystem most people reading this actually run. A few percent off the latency floor on writes matters.

Apple M3 Pro and Max

Linux 7.3 adds support for the M3 Pro and M3 Max. Base M3 was in 7.2. M3 Pro and Max use different memory configurations and the Pro variant has different core topology, which required separate work.

My interest in running Linux on Apple hardware is roughly zero. The fact that the kernel supports it is still worth noting because somebody is doing it, and the driver work that comes out of Apple Silicon support is sometimes useful on other ARM64 platforms.

what to track

7.3 stable is the kernel to land on if you run Gen5 NVMe and care about direct I/O throughput. The rest is incremental. The Linux 7.2 post has the context if you missed the cycle before this one.

Distros will lag by weeks to months. If you need the Gen5 fix now, you are compiling from source. The stable series at kernel.org gets backport patches; watch for it in 6.12.x and 6.18.x stable if you want the fix without tracking mainline.