Un parche de Linux 7.4 abre archivos un 39% más rápido

Un pequeño parche del núcleo Linux previsto para la versión 7.4 elevó un 39% el rendimiento de apertura de archivos en la prueba de su autor. Mateusz Guzik envió el cambio a la lista de correo linux-fsdevel el 3 de agosto de 2026, tras más de dos años de revisiones. Importa porque abrir archivos es una de las cosas que más hace un servidor cargado, y esta mejora no cuesta nada a cambio.

El parche se titula "fs: avoid spurious dentry ref/unref cycle on open". Afecta al sistema de archivos virtual, la capa del núcleo que se sitúa por encima de cada sistema de archivos concreto y atiende peticiones como open y read.

Qué cambia el parche

Un dentry es el registro que el núcleo guarda en caché para una entrada de directorio. Enlaza un nombre de una ruta con el archivo al que ese nombre apunta. El núcleo cuenta cuántas partes de sí mismo están usando cada dentry, para saber cuándo puede liberar el registro. Ese recuento es un contador de referencias.

El mensaje de commit de Guzik describe el desperdicio con claridad. Abrir un archivo toma una referencia sobre el dentry final en __legitimize_path(). Después toma una segunda en do_dentry_open(). Por último suelta la primera en terminate_walk().

Dos de esas tres operaciones no logran nada. El parche deja que do_dentry_open() consuma la referencia que el núcleo ya mantiene, en lugar de tomar una nueva y liberar la anterior.

El cambio es pequeño. El diff de la versión 5 añade 43 líneas y quita 4, repartidas en tres archivos: fs/internal.h, fs/namei.c y fs/open.c. Guzik lo describe como una alternativa más simple a un conjunto de parches más complejo de Al Viro, mantenedor veterano de este código.

El conteo de referencias parece barato por separado. No lo es cuando muchos núcleos de CPU tocan el mismo contador a la vez. Cada actualización debe hacerse visible para todos los demás núcleos, que acaban haciendo cola unos detrás de otros.

La prueba detrás del 39%

La cifra procede de will-it-scale, un conjunto de pruebas que mide cómo aguantan las operaciones del núcleo a medida que sube el número de núcleos. Guzik usó su caso openro3.c, que abre y cierra el mismo archivo en modo solo lectura dentro de un bucle.

En una máquina virtual de 20 núcleos, los resultados se movieron así.

Medición	Operaciones por segundo
Antes del parche	4.043.375
Después del parche	5.629.378

De ahí sale el 39%. Phoronix, que informó del parche el 19 de septiembre de 2026, señala que está a la espera en la rama vfs-7.4.lookup del árbol git del VFS, con vistas a la ventana de fusión de Linux 7.4.

Qué significa esto para los desarrolladores

Lee la prueba por lo que es. En el caso openro3 todos los núcleos abren un mismo archivo compartido, en solo lectura, dentro de un bucle cerrado. Eso maximiza la contención sobre justamente el contador que este parche deja de tocar, y por eso la mejora es tan grande. Es un techo, no un pronóstico para tu carga de trabajo.

Tu mejora dependerá de cuánto tiempo pasas abriendo archivos y de cuántos núcleos lo hacen a la vez. Hay tres cargas de trabajo cercanas a la prueba. Los sistemas de compilación consultan y abren miles de cabeceras. Los servidores web abren los mismos archivos estáticos en cada petición. Las herramientas de imágenes de contenedor y de paquetes recorren árboles de directorios grandes. Los scripts de un solo hilo en un portátil no notarán casi nada.

Puedes medir tu propia exposición antes de que llegue el núcleo. Cuenta las llamadas al sistema open y openat en una ejecución representativa con strace -c o un perfil de perf, y compáralo con el tiempo total. Si las aperturas son un detalle menor en tu perfil, este parche no es tu cuello de botella, diga lo que diga el titular.

No planifiques todavía con una fecha. El parche está en una rama de subsistema, es decir, aceptado por ese mantenedor pero aún no fusionado en el núcleo principal. Phoronix menciona la esperanza de llegar a los núcleos estables antes de que acabe 2026. Una ventana de fusión puede alterar ese orden, y después el código debe llegarte a través de un núcleo de distribución, lo que suele añadir meses.

La lección más amplia es la más útil. Este es un cambio de 43 líneas en una ruta que lleva décadas recorriéndose miles de millones de veces al día, y todavía tenía dos operaciones atómicas redundantes. Vale la pena releer las rutas críticas del código maduro. La serie de mejoras graduales del núcleo continúa: en el mismo ciclo 7.4, unos parches de kbuild recortaron los tiempos de compilación del núcleo.