Linux 7.4 patch opens files 39% faster in tests

A small Linux kernel patch queued for version 7.4 raised file-open throughput by 39% in its author's benchmark. Mateusz Guzik posted the change to the linux-fsdevel mailing list on August 3, 2026, after more than two years of revisions. It matters because opening files is one of the things a busy server does most, and this speedup costs nothing in return.

The patch is titled "fs: avoid spurious dentry ref/unref cycle on open". It touches the virtual file system, the kernel layer that sits above every individual file system and handles requests like open and read.

What the patch changes

A dentry is the kernel's cached record of a directory entry. It links a name in a path to the file that name points to. The kernel counts how many parts of itself are using each dentry, so it knows when the record can be freed. That count is a reference count.

Guzik's commit message describes the waste plainly. Opening a file takes a reference on the final dentry in __legitimize_path(). It then takes a second one in do_dentry_open(). Finally it drops the first in terminate_walk().

Two of those three operations achieve nothing. The patch lets do_dentry_open() consume the reference the kernel is already holding, instead of taking a fresh one and releasing the old one.

The change is small. The version 5 diff adds 43 lines and removes 4, across three files: fs/internal.h, fs/namei.c and fs/open.c. Guzik describes it as a simpler alternative to a more involved patch set from Al Viro, a longtime maintainer of this code.

Reference counting looks cheap in isolation. It is not cheap when many CPU cores hit the same counter at once. Each update has to be made visible to every other core, and they end up queuing behind each other.

The benchmark behind the 39%

The number comes from will-it-scale, a test suite that measures how kernel operations hold up as core counts rise. Guzik used its openro3.c case, which opens and closes the same file read-only in a loop.

On a 20-core virtual machine the results moved as follows.

Measurement	Operations per second
Before the patch	4,043,375
After the patch	5,629,378

That is the 39% figure. Phoronix, which reported the patch on September 19, 2026, notes it is queued in the VFS git tree's vfs-7.4.lookup branch for the Linux 7.4 merge window.

What this means for developers

Read the benchmark for what it is. The openro3 case has every core opening one shared file, read-only, in a tight loop. That maximizes contention on exactly the counter this patch stops touching, which is why the gain is so large. It is a ceiling, not a forecast for your workload.

Your own gain depends on how much of your time is spent opening files, and how many cores are doing it at once. Three workloads sit closest to the benchmark. Build systems stat and open thousands of headers. Web servers open the same static files for every request. Container image and package tooling walks large directory trees. Single-threaded scripts on a laptop will see close to nothing.

You can measure your own exposure before the kernel ships. Count the open and openat syscalls in a representative run with strace -c or a perf profile, and compare that against total runtime. If opens are a rounding error in your profile, this patch is not your bottleneck, whatever the headline says.

Do not plan around a date yet. The patch is queued in a subsystem branch, which means it is accepted by that maintainer but not yet merged into the mainline kernel. Phoronix reports the hope of reaching stable kernels before the end of 2026. A merge window can still reorder that, and the code then has to reach you through a distribution kernel, which usually adds months.

The wider lesson is the useful one. This is a 43-line change to a path that has been exercised billions of times a day for decades, and it still had two redundant atomic operations in it. Hot paths in mature code are worth re-reading, and the kernel's own history of incremental wins here continues: kbuild patches cut kernel build times in the same 7.4 cycle.