Torvalds usa Claude Code para rehacer la caché de páginas de Linux

Linus Torvalds, el creador de Linux, ha publicado un conjunto de parches del kernel que, según dice, se escribieron con Claude Code, el asistente de programación con IA de Anthropic. Los ocho parches cambian cómo Linux lee trozos pequeños de archivos que ya están en memoria. En su portátil, ocho hilos que leían el mismo archivo usaron unas cuatro veces menos ciclos de procesador por lectura. Nada está fusionado, y Torvalds enumera diez problemas abiertos.

Qué publicó Torvalds

Los parches están en una rama llamada noref-filemap-read-with-llm en el propio árbol del kernel de Torvalds. Una rama es una línea de cambios mantenida aparte del código principal. Los ocho parches de código llevan fecha del 7 al 10 de octubre de 2026 y se basan en Linux 7.3-rc6, una versión de prueba.

La descripción de la serie es clara sobre el papel de la IA.

El código, los programas de prueba, la revisión detrás de la lista anterior y el primer borrador de este texto los hizo un asistente de programación LLM (Claude Code) bajo mi dirección. Las mediciones se ejecutaron en mi máquina.

Cada parche de código lleva una línea «Assisted-by: LLM» junto a su propia firma.

Hardware Busters, un sitio de noticias de hardware, informó de la rama el 12 de octubre y señala que solo se midió en un portátil.

El mes pasado, Torvalds atribuyó a los LLM haber detectado errores corregidos en Linux 7.3-rc4.

El problema que resuelven los parches

Linux guarda en memoria los datos de archivos usados recientemente, en una zona llamada caché de páginas (page cache), para no tener que volver a leer el disco. Cada lectura de esa caché marca brevemente la memoria como «en uso» y luego quita la marca. Esa marca es un contador guardado junto a la página.

Cuando muchos hilos leen a la vez el mismo archivo pequeño, todos actualizan ese único contador. Cada núcleo del procesador tiene que tomar por turnos el mismo trozo de memoria, lo que frena a todos. Torvalds midió que el 99,92 % de este tráfico entre núcleos caía en una sola línea de memoria.

Según Hardware Busters, Matthew Wilcox planteó el problema por primera vez en 2024. Según Torvalds, las soluciones anteriores copiaban los datos a un búfer temporal y los comprobaban después, pero se atascaban en casos raros que la comprobación no podía detectar.

Cómo funcionan los parches

Cuando una página sale de la caché de páginas, Linux ahora espera antes de entregar esa memoria a otro. Espera un periodo de gracia de RCU, una ventana corta tras la cual se sabe que todos los lectores anteriores han terminado. RCU, siglas de read-copy-update, es un método del kernel que permite a los lectores trabajar sin bloqueos.

Como la memoria no se puede reutilizar mientras un lector aún la mira, la lectura ya no necesita el contador. Los datos se copian directamente al programa. Los intentos anteriores trataban de detectar casos raros e inseguros después de la copia. «Aplazar la liberación elimina esos casos en lugar de detectarlos», escribe Torvalds. Si ocurre algo inusual, como una página ausente o el final del archivo, el código vuelve a la ruta antigua.

Las cifras

Todas las cifras proceden de un portátil con un Intel Core i7-8565U, que tiene 4 núcleos y 8 hilos. Cada prueba leía 16 bytes de un archivo de una página. Torvalds advierte de que el portátil se ralentiza cuando se calienta, así que los ciclos por lectura se comparan mejor que las lecturas por segundo.

Prueba	Antes	Después
1 hilo, ciclos del kernel por lectura	452-454	408-409
8 hilos, ciclos del kernel por lectura	2.937-2.975	725-726
8 hilos, lecturas por segundo	9,9-10,4 millones	30-33 millones
8 hilos, conflictos de memoria entre núcleos (perf c2c)	30.538	101
1 hilo, lectura a un búfer que aún no está en memoria, ciclos	4.117-4.188	6.543-6.593

La última fila es el coste: cuando el búfer del programa aún no está en memoria, la nueva ruta falla una vez y retrocede. «Una máquina con más CPU, o con más de un socket, debería ganar más; no se ha medido nada mayor», escribe Torvalds.

Qué sigue sin resolverse

Retrasar la reutilización deja parte de la memoria inactiva. En una prueba, cuatro procesos liberaron rápidamente partes de un archivo en memoria. La memoria media en espera bajó de 565 MiB a 15 MiB tras dos parches adicionales. Esos parches fuerzan un periodo de gracia más rápido cuando más de 1.024 páginas esperan en un procesador. «El límite de 1024 páginas es una suposición», escribe Torvalds.

Su lista de problemas conocidos incluye:

• El asignador de memoria no ve las páginas en espera, así que el OOM killer puede actuar cuando cientos de MiB están a punto de liberarse.
• Las peticiones de bloques grandes de memoria contigua ahora pueden fallar con un error «busy».
• No se han ejecutado conjuntos de pruebas como xfstests, lockdep y KASAN, y no se ha probado ninguna máquina aparte de su portátil.
• En el planificador, escribe: «No estoy seguro de que esta sea la dirección».

Llama a la cuestión de la memoria «la parte de esta serie menos resuelta».

Qué significa para los desarrolladores

• Por ahora no cambia nada. La rama no está fusionada, y su descripción no nombra ninguna versión objetivo.
• Seguir la revisión. Las respuestas de los mantenedores de memoria, RCU y el planificador decidirán si el código se incorpora, se cambia o se descarta.
• Los lectores muy ocupados ganan más. El caso medido es el de muchos hilos leyendo un archivo pequeño en caché. Los equipos que ejecuten esa carga en servidores con muchos núcleos deberían probarlo.
• Una plantilla para parches asistidos por IA. Torvalds nombró la herramienta, firmó cada parche él mismo, publicó sus cifras en bruto y enumeró lo que no había probado. Los equipos que redactan reglas para el código escrito por IA pueden copiar esa forma.
• Revisar las herramientas de monitorización. Las lecturas por la ruta rápida omiten un tracepoint y el marcado habitual de «accedido», por lo que las herramientas que cuentan aciertos de la caché de páginas verían menos.