# Linux 7.4 patch opens files 39% faster in tests

URL: https://techaiwire.com/articles/linux-7-4-dentry-reference-faster-file-open/

_By Claire Whitmore - Sep 21, 2026_

**By the numbers:**

- 39% - more file opens per second in the test
- 43 - lines added across three files
- 20 - CPU cores on the test machine

**Same-file read-only opens per second, 20-core VM:**

- Before the patch: 4.04M
- After the patch: 5.63M

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"](https://marc.info/?l=linux-fsdevel&m=178576149734942&w=2). 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](https://www.phoronix.com/news/Linux-7.4-Faster-Do-Open), 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](/articles/linux-kbuild-patches-faster-builds/) in the same 7.4 cycle.

## Sources

- [[PATCH v5] fs: avoid spurious dentry ref/unref cycle on open](https://marc.info/?l=linux-fsdevel&m=178576149734942&w=2) - linux-fsdevel mailing list
- [Simple Optimization For Linux 7.4 Can Open Files For Reading ~39% Faster](https://www.phoronix.com/news/Linux-7.4-Faster-Do-Open) - Phoronix