Patch do Linux 7.4 abre arquivos 39% mais rápido em testes

Um pequeno patch do núcleo Linux previsto para a versão 7.4 aumentou em 39% a taxa de abertura de arquivos no teste do próprio autor. Mateusz Guzik enviou a mudança à lista de discussão linux-fsdevel em 3 de agosto de 2026, depois de mais de dois anos de revisões. Isso importa porque abrir arquivos é uma das tarefas mais frequentes de um servidor ocupado, e esse ganho não cobra nada em troca.

O patch se chama "fs: avoid spurious dentry ref/unref cycle on open". Ele mexe no sistema de arquivos virtual, a camada do núcleo que fica acima de cada sistema de arquivos e trata pedidos como open e read.

O que o patch muda

Um dentry é o registro que o núcleo mantém em cache para uma entrada de diretório. Ele liga um nome dentro de um caminho ao arquivo para o qual esse nome aponta. O núcleo conta quantas partes de si mesmo estão usando cada dentry, para saber quando o registro pode ser liberado. Essa contagem é um contador de referências.

A mensagem de commit de Guzik descreve o desperdício com clareza. Abrir um arquivo toma uma referência ao dentry final em __legitimize_path(). Em seguida toma uma segunda em do_dentry_open(). Por fim libera a primeira em terminate_walk().

Duas dessas três operações não realizam nada. O patch deixa do_dentry_open() consumir a referência que o núcleo já mantém, em vez de tomar uma nova e soltar a antiga.

A mudança é pequena. O diff da versão 5 acrescenta 43 linhas e remove 4, distribuídas em três arquivos: fs/internal.h, fs/namei.c e fs/open.c. Guzik a descreve como uma alternativa mais simples a um conjunto de patches mais complexo de Al Viro, mantenedor antigo desse código.

A contagem de referências parece barata isoladamente. Ela não é barata quando muitos núcleos de CPU tocam o mesmo contador ao mesmo tempo. Cada atualização precisa ficar visível para todos os outros núcleos, que acabam enfileirados uns atrás dos outros.

O teste por trás dos 39%

O número vem do will-it-scale, um conjunto de testes que mede como as operações do núcleo se sustentam conforme a contagem de núcleos cresce. Guzik usou o caso openro3.c, que abre e fecha o mesmo arquivo somente para leitura dentro de um laço.

Em uma máquina virtual de 20 núcleos, os resultados se moveram assim.

Medição	Operações por segundo
Antes do patch	4.043.375
Depois do patch	5.629.378

Daí vem o número de 39%. O Phoronix, que noticiou o patch em 19 de setembro de 2026, observa que ele aguarda no ramo vfs-7.4.lookup da árvore git do VFS, mirando a janela de integração do Linux 7.4.

O que isso significa para desenvolvedores

Leia o teste pelo que ele é. No caso openro3, todos os núcleos abrem um mesmo arquivo compartilhado, somente para leitura, em um laço apertado. Isso maximiza a disputa justamente pelo contador que este patch deixa de tocar, e é por isso que o ganho é tão grande. Ele é um teto, não uma previsão para a sua carga de trabalho.

Seu ganho depende de quanto tempo você gasta abrindo arquivos e de quantos núcleos fazem isso ao mesmo tempo. Três cargas de trabalho ficam mais próximas do teste. Sistemas de compilação consultam e abrem milhares de cabeçalhos. Servidores web abrem os mesmos arquivos estáticos a cada requisição. Ferramentas de imagens de contêiner e de pacotes percorrem grandes árvores de diretórios. Scripts de thread única em um notebook não verão quase nada.

Você pode medir sua própria exposição antes de o núcleo chegar. Conte as chamadas de sistema open e openat em uma execução representativa com strace -c ou um perfil do perf e compare com o tempo total. Se as aberturas forem irrelevantes no seu perfil, este patch não é o seu gargalo, diga o que disser a manchete.

Ainda não faça planos com uma data. O patch está em um ramo de subsistema, ou seja, foi aceito por aquele mantenedor, mas ainda não foi integrado ao núcleo principal. O Phoronix relata a expectativa de chegar aos núcleos estáveis antes do fim de 2026. Uma janela de integração pode mudar essa ordem, e depois o código ainda precisa alcançar você por um núcleo de distribuição, o que costuma somar meses.

A lição mais ampla é a mais útil. Esta é uma mudança de 43 linhas em um caminho percorrido bilhões de vezes por dia há décadas, e ele ainda tinha duas operações atômicas redundantes. Caminhos críticos em código maduro merecem uma releitura. A série de ganhos graduais do núcleo continua: no mesmo ciclo 7.4, patches do kbuild reduziram os tempos de compilação do núcleo.