Linus Torvalds, creador de Linux y principal responsable del desarrollo del núcleo, utilizó la herramienta Claude Code de Anthropic para ayudar a solucionar un cuello de botella de más de dos años en la ruta de lectura de archivos. Una serie de 10 parches proporcionó una mejora de hasta 23 veces en la tasa de lectura en una prueba sintética ejecutada en un equipo Threadripper de 64 núcleos, pero los revisores del núcleo de Linux descubrieron posteriormente una condición de carrera y plantearon preguntas sobre la seguridad del diseño de recuperación de memoria, lo que significa que los parches aún no se han integrado.
Un problema en los contadores de referencias de la memoria de páginas
El trabajo está relacionado con una contención en los contadores de referencias de objetos conocidos como folios dentro de la caché de páginas, una capa que conserva los datos leídos de los archivos para acelerar el acceso. El cuello de botella se notificó en 2024 después de aparecer en la carga de trabajo de un cliente, y las pruebas realizadas en el portátil de Torvalds mostraron que esta contención representaba el 99,92 % de las operaciones HITM entre los núcleos en una prueba que utilizaba ocho hilos.
Torvalds afirmó que pasó 18 meses ejecutando una versión defectuosa de su corrección anterior para el problema, mientras que otros desarrolladores encontraron problemas en sus intentos. Los nuevos parches buscan eliminar las operaciones de incremento y decremento de referencias de folios de la ruta de lectura en caché más utilizada, aunque Torvalds advirtió que las ganancias serían mucho menores en cargas de trabajo reales que en la prueba sintética.
El papel de Claude Code y los límites del resultado
En el árbol de Torvalds apareció una rama experimental llamada noref-filemap-read-with-llm, y posteriormente la serie incluyó una explicación del papel de Claude Code. Según lo expuesto por Torvalds, la herramienta escribió la implementación, las pruebas y la documentación inicial, además de revisar el código bajo su dirección, mientras que él se encargó de ejecutar personalmente las pruebas de rendimiento.
La primera serie elevó la tasa de lectura en su portátil de unos 10 millones a 33 millones de lecturas por segundo y redujo el número de ciclos del núcleo por lectura de aproximadamente 2.950 a 725. La serie revisada elevó el rendimiento en un equipo Threadripper de 13,3 millones a 304 millones de lecturas por segundo bajo una carga elevada, con una reducción de los ciclos por lectura de cerca de 20.000 a 735.
¿Por qué no bastan las cifras de rendimiento?
La mejora vino acompañada de posibles costes. La primera implementación imponía un periodo de espera urgente cuando la CPU superaba las 1.024 páginas pendientes de recuperación. Además, las lecturas que accedían a páginas de usuario no vinculadas provocaban una comprobación adicional antes de volver a la ruta existente, por lo que el coste de una lectura de un solo hilo de 16 bytes aumentaba de unas 4.150 a 6.550 ciclos. Aún no está claro si esta regresión permanecerá en la versión rcu-free-v3.
La revisión reveló el riesgo más importante
Matthew Wilcox cuestionó el uso de la nueva bandera PG_rcu_free y propuso una alternativa basada en el tipo de página y en un mecanismo diferente para recuperar folios inactivos. Kiryl Shutsemau también propuso limitar la bandera a los sistemas de 64 bits, una dirección respaldada por David Hildenbrand.
Shutsemau descubrió además una condición de carrera en la función filemap_read_rcu_batch(): la sustitución de un folio seguida de una ampliación del tamaño del archivo podría exponer datos que en realidad no se habían escrito. Torvalds propuso leer antes el tamaño del archivo y agrupar las operaciones de comprobación, lo que se incorporó a un parche revisado.
Lectura editorial de certi.news: el caso muestra que las herramientas de programación basadas en inteligencia artificial pueden alcanzar rápidamente grandes mejoras en pruebas del núcleo, pero no eliminan la necesidad de una revisión especializada que comprenda la concurrencia y el ciclo de vida de la memoria. Las cifras récord demuestran aquí una ganancia en un entorno específico, no una preparación automática para la integración ni una garantía de seguridad de la implementación.