Una rama que dice quién la escribió
Una rama llamada noref-filemap-read-with-llm apareció el fin de semana pasado en el propio árbol del kernel de Linus Torvalds. Contiene ocho parches, todos escritos y confirmados por Torvalds entre el 9 y el 10 de octubre, sobre 7.3-rc6. El último es un commit vacío que no lleva más que la explicación, y cerca del final de ese texto, bajo un epígrafe titulado “Tools”, hay un párrafo que pocos commits del kernel contienen:
“El código, los programas de prueba, la revisión que hay detrás de la lista anterior y el primer borrador de este texto se hicieron con un asistente de programación basado en un LLM (Claude Code) bajo mi dirección. Las mediciones se ejecutaron en mi máquina.”
Phoronix, que encontró la rama mientras esperaba la 7.3-rc7, señaló que Torvalds casi nunca mantiene ramas de trabajo en su repositorio principal. Los ocho commits no están en master, y él no ha dicho si entrarán en la ventana de fusión de la 7.4.
El problema es una línea de caché
La serie ataca un problema de contención que Matthew Wilcox planteó en 2024 a partir de la carga de trabajo de un cliente. Cuando muchos hilos leen cantidades pequeñas del mismo archivo, cada lectura toma y suelta una referencia sobre el folio que contiene la página, así que cada una escribe dos veces la misma línea de caché de struct page. En el portátil de Torvalds —un i7-8565U de cuatro núcleos y ocho hilos— ocho hilos haciendo llamadas pread() de 16 bytes sobre una sola página concentran el 99,92% de los load HITMs en esa línea.
Su solución es dejar de tomar la referencia. Un folio retirado de la caché de páginas vuelve ahora al asignador de páginas solo tras un periodo de gracia de RCU, lo que significa que una página encontrada bajo rcu_read_lock() sigue conteniendo los datos de ese archivo hasta que se suelta el bloqueo. La lectura copia entonces directamente al búfer del usuario con los fallos de página desactivados: sin referencia, sin búfer intermedio en la pila, sin comprobación posterior a la copia y sin límite de tamaño.
Los intentos anteriores, escribe Torvalds, copiaban sin referencia a un búfer en la pila y validaban después, y “se detuvieron en lo que la validación no puede ver”: liberación, reutilización y reinserción en el mismo índice, migración, y lectura de memoria que ya no es caché de páginas en absoluto, incluidas secretmem, la memoria no aceptada e “incluso peor, MMIO con efectos de lectura indeseados”. Diferir la liberación elimina esos casos en vez de detectarlos.
Tres veces las lecturas, y de 30.538 HITMs a 101
Las cifras del mensaje del commit salen de una sola máquina, con ext4 y con las mitigaciones de CPU y CONFIG_HARDENED_USERCOPY desactivadas. Con ocho hilos leyendo 16 bytes de una página, el kernel base logra entre 9,9 y 10,4 millones de lecturas por segundo a 2.937–2.975 ciclos de kernel por lectura. Con la serie logra entre 30 y 33 millones a 725–726 ciclos. Cuatro hilos, uno por núcleo, pasan de 8,9–11,6 millones a 25–26 millones. Los load HITMs medidos con perf c2c caen de 30.538 a 101.
El coste es la memoria que queda en cola esperando un periodo de gracia, y es la parte que Torvalds llama la menos resuelta. La objeción de Wilcox a diferir la liberación, citada en el mensaje, era que “simplemente parece demasiado arriesgado tener tanta memoria esperando a ser reutilizada”. Los parches 7 y 8 existen para contener eso: por encima de 1.024 páginas pendientes en una CPU, un segundo elemento de trabajo llama a synchronize_rcu_expedited() y libera la lista, lo que con cuatro procesos haciendo agujeros ocurre 4.600 veces por segundo, algo que la propia documentación de esa función dice que no se haga en bucle. Torvalds lo señala él mismo: “¿Hay alguna manera de obtener un periodo de gracia corto sin ellas?”
Lo que dice que no ha probado
El mensaje termina con una lista de aquello contra lo que la serie no se ha ejecutado: presión de memoria más allá de un reproductor en una máquina virtual, lockdep, KASAN, un kernel compilado con clang, 32 bits, CONFIG_HARDENED_USERCOPY y “cualquier máquina que no sea esta”. Sobre el cambio en el planificador del parche 8 escribe: “No estoy seguro de que sea la dirección; preferiría que la tarea que libera hiciera algo síncrono que dejara en paz al planificador.”
Esa es la parte que conviene vigilar, más que la herramienta. Torvalds ha publicado una serie de gestión de memoria crítica para el rendimiento, ha atribuido el código a un asistente, se ha reservado las mediciones y ha dejado dos preguntas abiertas a los mantenedores del subsistema. Que sobreviva a la revisión en la lista de correo es una prueba distinta de que corriera rápido en su portátil.
