Torvalds usa o Claude Code para refazer o cache de páginas do Linux

Linus Torvalds, o criador do Linux, publicou um conjunto de patches do kernel que, segundo ele, foram escritos com o Claude Code, o assistente de programação com IA da Anthropic. Os oito patches mudam como o Linux lê pequenos trechos de arquivos que já estão na memória. No notebook dele, oito threads lendo o mesmo arquivo usaram cerca de quatro vezes menos ciclos de processador por leitura. Nada foi incorporado, e Torvalds lista dez problemas em aberto.

O que Torvalds publicou

Os patches estão em um branch chamado noref-filemap-read-with-llm na própria árvore do kernel de Torvalds. Um branch é uma linha de mudanças mantida separada do código principal. Os oito patches de código têm data de 7 a 10 de outubro de 2026 e se baseiam no Linux 7.3-rc6, uma versão de teste.

A descrição da série é direta sobre o papel da IA.

O código, os programas de teste, a revisão por trás da lista acima e o primeiro rascunho deste texto foram feitos por um assistente de programação LLM (Claude Code) sob minha direção. As medições foram executadas na minha máquina.

Cada patch de código traz uma linha "Assisted-by: LLM" ao lado da própria assinatura dele.

O Hardware Busters, um site de notícias de hardware, noticiou o branch em 12 de outubro e observa que ele foi medido em apenas um notebook.

No mês passado, Torvalds creditou aos LLMs a descoberta de bugs corrigidos no Linux 7.3-rc4.

O problema que os patches resolvem

O Linux mantém na memória os dados de arquivos usados recentemente, em uma área chamada cache de páginas (page cache), para não precisar ler o disco de novo. Cada leitura desse cache marca brevemente a memória como "em uso" e depois tira a marca. Essa marca é um contador guardado junto com a página.

Quando muitas threads leem o mesmo arquivo pequeno ao mesmo tempo, todas atualizam esse único contador. Cada núcleo do processador precisa pegar, em turnos, o mesmo pedaço de memória, o que deixa todos mais lentos. Torvalds mediu que 99,92% desse tráfego entre núcleos caía em uma única linha de memória.

Segundo o Hardware Busters, Matthew Wilcox levantou o problema pela primeira vez em 2024. Segundo Torvalds, correções anteriores copiavam os dados para um buffer temporário e os verificavam depois, mas travavam em casos raros que a verificação não conseguia detectar.

Como os patches funcionam

Quando uma página sai do cache de páginas, o Linux agora espera antes de entregar essa memória a outra pessoa. Ele espera um período de carência do RCU, uma janela curta após a qual se sabe que todos os leitores anteriores terminaram. RCU, sigla de read-copy-update, é um método do kernel que permite aos leitores trabalhar sem bloqueios.

Como a memória não pode ser reutilizada enquanto um leitor ainda olha para ela, a leitura não precisa mais do contador. Os dados são copiados direto para o programa. Tentativas anteriores buscavam pegar casos raros e inseguros depois da cópia. "Adiar a liberação elimina esses casos em vez de detectá-los", escreve Torvalds. Se algo incomum acontecer, como uma página ausente ou o fim do arquivo, o código volta ao caminho antigo.

Os números

Todos os números vêm de um notebook com Intel Core i7-8565U, que tem 4 núcleos e 8 threads. Cada teste lia 16 bytes de um arquivo de uma página. Torvalds avisa que o notebook fica mais lento quando esquenta, então os ciclos por leitura são mais justos de comparar do que as leituras por segundo.

Teste	Antes	Depois
1 thread, ciclos do kernel por leitura	452-454	408-409
8 threads, ciclos do kernel por leitura	2.937-2.975	725-726
8 threads, leituras por segundo	9,9-10,4 milhões	30-33 milhões
8 threads, conflitos de memória entre núcleos (perf c2c)	30.538	101
1 thread, leitura para um buffer ainda não na memória, ciclos	4.117-4.188	6.543-6.593

A última linha mostra o custo: quando o buffer do programa ainda não está na memória, o novo caminho falha uma vez e volta atrás. "Uma máquina com mais CPUs, ou com mais de um soquete, deve ganhar mais; nada maior foi medido", escreve Torvalds.

O que ainda não foi resolvido

Adiar a reutilização deixa parte da memória parada. Em um teste, quatro processos liberaram rapidamente partes de um arquivo na memória. A memória média em espera caiu de 565 MiB para 15 MiB depois de dois patches extras. Esses patches forçam um período de carência mais rápido quando mais de 1.024 páginas esperam em um processador. "O limite de 1024 páginas é um palpite", escreve Torvalds.

A lista dele de problemas conhecidos inclui:

• O alocador de memória não enxerga as páginas em espera, então o OOM killer pode agir quando centenas de MiB estão prestes a ser liberadas.
• Pedidos de grandes blocos de memória contígua agora podem falhar com um erro "busy".
• Suítes de testes como xfstests, lockdep e KASAN não foram executadas, e nenhuma máquina além do notebook dele foi testada.
• No escalonador, ele escreve: "Não tenho certeza de que esta é a direção."

Ele chama a questão da memória de "a parte desta série menos resolvida".

O que isso significa para os desenvolvedores

• Nada muda por enquanto. O branch não foi incorporado, e a descrição dele não cita nenhuma versão-alvo.
• Acompanhe a revisão. As respostas dos mantenedores de memória, RCU e escalonador vão decidir se o código entra, muda ou é descartado.
• Leitores muito ocupados ganham mais. O caso medido é o de muitas threads lendo um arquivo pequeno em cache. Equipes que executam essa carga em servidores com muitos núcleos devem testá-lo.
• Um modelo para patches assistidos por IA. Torvalds citou a ferramenta, assinou cada patch pessoalmente, publicou seus números brutos e listou o que não tinha testado. Equipes que escrevem regras para código feito por IA podem copiar esse formato.
• Verifique as ferramentas de monitoramento. Leituras no caminho rápido pulam um tracepoint e a marcação usual de "acessado", então ferramentas que contam acertos no cache de páginas veriam menos deles.