Linus Torvalds, criador do Linux e principal responsável pelo desenvolvimento do kernel, usou a ferramenta Claude Code, da Anthropic, para ajudar a tratar um gargalo com mais de dois anos no caminho de leitura de arquivos. Uma série de 10 patches proporcionou uma melhoria de 23 vezes na taxa de leitura em um teste sintético realizado em uma máquina Threadripper de 64 núcleos, mas revisores do kernel Linux descobriram posteriormente uma condição de corrida e levantaram questões sobre a segurança do projeto de recuperação de memória, o que significa que os patches ainda não foram integrados.
Um problema nos contadores de referência da memória de páginas
O trabalho está relacionado à contenção nos contadores de referência de objetos conhecidos como folios dentro do page cache, uma camada que mantém os dados lidos dos arquivos para acelerar o acesso a eles. O gargalo foi relatado em 2024, depois de aparecer na carga de trabalho de um cliente, e testes no laptop de Torvalds mostraram que essa contenção representava 99,92% das operações HITM entre os núcleos em um teste que usava oito threads.
Torvalds disse que passou 18 meses executando uma versão defeituosa de sua correção anterior para o problema, enquanto outros desenvolvedores enfrentaram problemas em suas tentativas. Os novos patches têm como objetivo remover as operações de incremento e decremento das referências de folio do caminho de leitura em cache mais utilizado, com Torvalds alertando que os ganhos serão muito menores em cargas de trabalho reais em comparação com o teste sintético.
O papel do Claude Code e os limites do resultado
Uma branch experimental chamada noref-filemap-read-with-llm apareceu na árvore de Torvalds, e a série posteriormente incluiu uma explicação sobre o papel do Claude Code. Segundo Torvalds, a ferramenta escreveu a implementação, os testes e a documentação inicial, além de revisar o código sob sua orientação, enquanto ele próprio executou os testes de desempenho.
A primeira série elevou a taxa de leitura em seu laptop de cerca de 10 milhões para 33 milhões de leituras por segundo e reduziu o número de ciclos do kernel por leitura de aproximadamente 2.950 para 725. Já a série revisada elevou o desempenho em uma máquina Threadripper de 13,3 milhões para 304 milhões de leituras por segundo sob alta pressão, com uma redução dos ciclos por leitura de cerca de 20.000 para 735.
Por que os números de desempenho não são suficientes?
A melhoria veio acompanhada de possíveis custos. A primeira implementação impunha um período de espera forçada quando a CPU ultrapassava 1.024 páginas pendentes de recuperação. Além disso, leituras em páginas de usuário não vinculadas geravam um custo adicional antes de retornar ao caminho existente, elevando o custo de uma leitura de thread único de 16 bytes de aproximadamente 4.150 para 6.550 ciclos. Ainda não está claro se esse retrocesso permanecerá na versão rcu-free-v3.
A revisão revelou o risco mais importante
Matthew Wilcox contestou o uso da nova flag PG_rcu_free e propôs uma alternativa baseada no tipo de página e em um mecanismo diferente para recuperar folios inativos. Kiryl Shutsemau também propôs limitar a flag a sistemas de 64 bits, uma direção apoiada por David Hildenbrand.
Shutsemau também descobriu uma condição de corrida na função filemap_read_rcu_batch(): a substituição de um folio seguida da expansão do tamanho do arquivo poderia expor dados que, na prática, não haviam sido gravados. Torvalds propôs ler o tamanho do arquivo mais cedo e agrupar as operações de verificação, o que foi incluído em um patch revisado.
Leitura editorial da certi.news: o caso mostra que ferramentas de programação com inteligência artificial conseguem alcançar rapidamente grandes melhorias em testes do kernel, mas não eliminam a necessidade de uma revisão especializada que compreenda concorrência e o ciclo de vida da memória. Os números recordes aqui comprovam um ganho em um ambiente específico, não uma prontidão automática para integração nem uma garantia de segurança da implementação.