Um ramo que diz quem o escreveu
Um ramo chamado noref-filemap-read-with-llm apareceu no fim de semana passado na própria árvore do kernel de Linus Torvalds. Contém oito patches, todos escritos e submetidos por Torvalds entre 9 e 10 de outubro, por cima do 7.3-rc6. O último é um commit vazio que não traz mais do que a explicação, e perto do fim desse texto, sob um subtítulo “Tools”, há um parágrafo que poucos commits do kernel contêm:
“O código, os programas de teste, a revisão por trás da lista acima e o primeiro rascunho deste texto foram feitos com um assistente de programação baseado num LLM (Claude Code) sob a minha direção. As medições correram na minha máquina.”
O Phoronix, que encontrou o ramo enquanto esperava pelo 7.3-rc7, notou que Torvalds quase nunca mantém ramos de trabalho no seu repositório principal. Os oito commits não estão no master, e ele não disse se irão para a janela de fusão do 7.4.
O problema é uma linha de cache
A série ataca um problema de contenção que Matthew Wilcox levantou em 2024 a partir da carga de trabalho de um cliente. Quando muitas threads leem pequenas quantidades do mesmo ficheiro, cada leitura toma e larga uma referência sobre o folio que segura a página, pelo que cada uma escreve duas vezes a mesma linha de cache do struct page. No portátil de Torvalds — um i7-8565U de quatro núcleos e oito threads — oito threads a fazer chamadas pread() de 16 bytes sobre uma única página concentram 99,92% dos load HITMs nessa linha.
A sua solução é deixar de tomar a referência. Um folio retirado da cache de páginas volta agora ao alocador apenas depois de um período de graça do RCU, o que significa que uma página encontrada sob rcu_read_lock() continua a conter os dados desse ficheiro até o bloqueio ser libertado. A leitura copia então diretamente para o buffer do utilizador com as falhas de página desativadas: sem referência, sem buffer intermédio na pilha, sem verificação depois da cópia e sem limite de tamanho.
As tentativas anteriores, escreve Torvalds, copiavam sem referência para um buffer na pilha e validavam depois, e “pararam naquilo que a validação não consegue ver”: libertação, reutilização e reinserção no mesmo índice, migração, e leitura de memória que já não é cache de páginas de todo, incluindo secretmem, memória não aceite e “ou pior ainda MMIO com efeitos de leitura indesejados”. Adiar a libertação elimina esses casos em vez de os detetar.
Três vezes as leituras, e 30 538 HITMs reduzidos a 101
Os números da mensagem de commit vêm de uma só máquina, com ext4 e com as mitigações de CPU e o CONFIG_HARDENED_USERCOPY desligados. Com oito threads a ler 16 bytes de uma página, o kernel base consegue 9,9 a 10,4 milhões de leituras por segundo a 2 937–2 975 ciclos de kernel por leitura. Com a série consegue 30 a 33 milhões a 725–726 ciclos. Quatro threads, uma por núcleo, passam de 8,9–11,6 milhões para 25–26 milhões. Os load HITMs medidos com perf c2c caem de 30 538 para 101.
O custo é a memória que fica em fila à espera de um período de graça, e é a parte que Torvalds diz estar menos resolvida. A objeção de Wilcox a adiar a libertação, citada na mensagem, era que “parece simplesmente arriscado demais ter tanta memória à espera de ser reutilizada”. Os patches 7 e 8 existem para conter isso: acima de 1 024 páginas pendentes num CPU, um segundo item de trabalho chama synchronize_rcu_expedited() e liberta a lista, o que com quatro processos a furar ficheiros acontece 4 600 vezes por segundo — algo que a documentação da própria função diz para não fazer em ciclo. Torvalds assinala-o ele mesmo: “Haverá maneira de obter um período de graça curto sem elas?”
O que diz não ter testado
A mensagem termina com uma lista do que a série não correu contra: pressão de memória além de um único reprodutor numa máquina virtual, lockdep, KASAN, um kernel compilado com clang, 32 bits, CONFIG_HARDENED_USERCOPY e “qualquer máquina que não esta”. Sobre a alteração ao escalonador no patch 8 escreve: “Não tenho a certeza de que seja a direção; preferia que a tarefa que liberta fizesse algo síncrono que deixasse o escalonador em paz.”
É essa a parte a seguir, mais do que a ferramenta. Torvalds publicou uma série de gestão de memória crítica para o desempenho, atribuiu o código a um assistente, guardou as medições para si e deixou duas perguntas em aberto aos mantenedores dos subsistemas. Sobreviver à revisão na lista de correio é um teste diferente de ter corrido depressa no seu portátil.
