Torvalds y Claude Code reescriben el page cache: 23x y una race

Esta semana Linus Torvalds publicó una rama de kernel hecha con Claude Code que cambia cómo Linux lee archivos cacheados. Los números son llamativos, pero el parche todavía no está mergeado y los revisores ya encontraron una race condition. Para quien opera servidores Linux, la nota útil no es "la IA escribió kernel" sino qué patrón de carga mejora, qué riesgos quedan abiertos y cómo medir si te afecta.

El page cache de Linux es la parte de la memoria donde el kernel guarda copias de bloques de archivos para no volver al disco en cada lectura. Lo usan todos los procesos que leen archivos con read() o pread(). Los parches de Torvalds apuntan a un cuello de botella concreto: leer porciones chicas del mismo archivo desde muchos hilos a la vez, donde hoy compite el contador de referencias del folio.

¿Qué cambió exactamente en el camino de lectura del page cache?

Los parches eliminan la referencia atómica sobre el folio durante las lecturas chicas. En lugar de incrementar y decrementar un contador por cada read(), el lector copia los datos dentro de una sección crítica RCU, y el kernel posterga la liberación de esas páginas hasta que termina un grace period de RCU.

• El problema de base es cache-line bouncing. Según la cobertura de The New Stack, cada lectura toma y suelta una referencia atómica sobre la misma estructura, y esa línea de caché rebota de core en core cuando hay muchos hilos.
• La solución es diferir la liberación. Con RCU, el lector no necesita "agarrar" el folio: lo que se libera espera un grace period antes de reutilizarse.
• Hay una válvula de seguridad para la memoria. Según el análisis de DEV Community sobre la rama, dos parches fuerzan un grace period acelerado cuando una CPU acumula más de 1.024 páginas pendientes de liberar.
• La rama se llama noref-filemap-read-with-llm. Phoronix la reportó el 11 de octubre de 2026 y aclaró que habrá que ver si Torvalds la mergea para la ventana de Linux 7.4.

¿De dónde sale el "23x" y es un número confiable?

El 23x es real pero acotado: viene de un benchmark sintético en un Threadripper de 64 hilos, bajo fuerte contención. Es un techo para el peor caso de contención, no una mejora esperable en una aplicación real. Por eso conviene mirar las dos tandas de números que circulan.

Los datos de la primera fila los detalla el análisis de DEV Community sobre la rama original. Los de la segunda fila salen de la nota de The New Stack (14 de octubre de 2026). Tampoco encontré la serie en el hilo original de la lista de correo, y recomiendo verificarlo ahí antes de citarlo.

Dos matices que no aparecen en los titulares:

• Hay una regresión en el caso de un solo hilo. Según el análisis de DEV Community, las lecturas chicas de páginas no mapeadas pasaron de unos 4.150 a unos 6.550 ciclos.
• Las pruebas son de una sola máquina. Las mediciones de la primera tanda se hicieron en el equipo de Torvalds y con mitigaciones de CPU desactivadas, algo que no vas a tener en producción.

¿Qué race condition encontraron los revisores?

Kiryl Shutsemau detectó una race en filemap_read_rcu_batch(): si un folio se reemplaza y después se extiende i_size, una lectura podía exponer datos que nunca se escribieron. Es el tipo de bug que no rompe un benchmark pero sí la integridad de datos, y por eso la revisión humana pesa más que el número.

• Torvalds propuso un arreglo. Sugirió leer el tamaño del archivo antes y consolidar los chequeos del folio, y Shutsemau lo incorporó en un parche revisado que sigue en discusión.
• Shutsemau toma la posta. Había trabajado antes sobre el mismo cuello de botella, y Torvalds le pasó el desarrollo posterior.
• Hay objeciones de diseño sobre el flag PG_rcu_free. Según los resultados de búsqueda sobre la discusión, Matthew Wilcox y Shutsemau cuestionaron cómo se reclama la memoria.
• La liberación diferida es el punto débil admitido. Según DEV Community, Torvalds la describió como la parte de la serie "least solved", y una versión previa provocó OOM kills en pruebas de estrés con 4 a 8 CPUs.

¿Qué papel tuvo Claude Code y por qué importa?

Claude Code escribió el código, los programas de prueba y el primer borrador del texto, pero la dirección, las mediciones y la responsabilidad quedaron en manos de Torvalds. Él mismo lo dejó escrito en el commit principal, según Phoronix: "The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction."

Mi lectura: el caso es más interesante por el proceso que por el modelo. Hubo un humano que sabía exactamente qué problema atacar, un benchmark que lo hace visible y una revisión pública que encontró una race que la generación no vio. Si trabajás con código asistido por IA, es el mismo patrón que conviene aplicar en tus repos: la IA acelera el borrador, pero el control de calidad sigue siendo humano. Para un cambio de memoria concurrente, "compila y el benchmark mejora" no alcanza.

¿Esto afecta a mi servidor en producción hoy?

No, hoy no te afecta: la rama no está mergeada y, aunque entre a Linux 7.4, tardaría en llegar a kernels de distribución. Lo que sí podés hacer es medir si tu carga tiene el patrón que este trabajo ataca: muchos hilos leyendo pedazos chicos del mismo archivo ya cacheado.

• Cargas con el patrón potencial. Servicios con muchos workers leyendo un mismo archivo caliente (un índice, un archivo de datos compartido, un binario) con lecturas chicas. Es una inferencia mía a partir del mecanismo, no algo que digan las fuentes.
• Cargas que probablemente no se enteren. Bases de datos que leen bloques grandes y ya tienen su propio buffer (por ejemplo, PostgreSQL con shared_buffers), o cargas limitadas por disco o red. También es inferencia: probalo antes de asumirlo.
• Cargas con mucho I/O contra almacenamiento lento. Ahí el cuello de botella está debajo del page cache. Es el tema de nuestra nota Postgres no es lento, tu disco sí.

¿Cómo detecto contención en el page cache?

Con perf podés buscar cache-line bouncing sobre una carga real. Un resultado con muchos HITM (cargas que pegan en una línea modificada por otro core) sobre estructuras de folio sugiere que esta clase de optimización te interesa. En la rama de Torvalds, según DEV Community, los load HITMs bajaron de 30.538 a 101.

# Versión de kernel actual
uname -r

# Contención de cache lines durante 30 s con tu carga corriendo
sudo perf c2c record -a -- sleep 30
sudo perf c2c report --stdio | head -n 80

# Reproducción sintética parecida (ajustá archivo, tamaño y runtime)
fio --name=smallread --filename=/data/testfile --size=1G \
    --rw=randread --bs=64 --ioengine=psync --numjobs=8 \
    --time_based --runtime=30 --group_reporting

Tomá estos comandos como punto de partida, no como un protocolo validado: el tamaño de bloque mínimo y los resultados dependen del kernel y del filesystem. Corrélos primero en un entorno de prueba.

¿Qué hay que mirar de acá en adelante?

Hay tres señales que vale la pena seguir: si la serie se mergea en la ventana de Linux 7.4, cómo queda resuelta la liberación diferida bajo presión de memoria, y si aparecen benchmarks de terceros con cargas reales. Hasta que pasen esas tres cosas, tratá los números de Torvalds como una prueba de concepto.

• Seguí el estado del merge. Phoronix y la lista de correo de memory management son las fuentes más directas.
• No hagas backports por tu cuenta. Es un cambio de concurrencia en una ruta crítica que ni siquiera cerró la revisión.
• Medí tu línea base ahora. Si guardás los números actuales de perf, cuando llegue un kernel con el cambio vas a poder comparar con datos propios.

Si querés ver cómo evoluciona el kernel en otros frentes, tenemos una nota sobre Linux 7.3 y sched_ext, que cubre scheduling con BPF por cgroup.

Preguntas frecuentes

¿Cuándo llegaría este cambio a un kernel estable?

No hay fecha: la rama sigue sin mergear y todavía está en revisión. Phoronix apuntó a la ventana de Linux 7.4 como posibilidad, no como confirmación, y después habría que esperar a que las distribuciones lo incorporen.

¿Mejora las lecturas de cualquier aplicación?

No, apunta a lecturas pequeñas y concurrentes sobre el mismo archivo cacheado. Según The New Stack, Torvalds mismo advirtió que las cargas reales verían mejoras considerablemente menores que el benchmark sintético.

¿Se puede confiar en código de kernel escrito con IA?

Depende de la revisión, no de la herramienta. En este caso la revisión humana encontró una race condition que ningún benchmark mostraba, y Torvalds asumió la responsabilidad del código. Con IA o sin ella, los cambios de concurrencia exigen revisión experta y pruebas de estrés.

¿Por qué hay dos juegos de números distintos (3x y 23x)?

Corresponden a iteraciones y equipos distintos. La rama de 8 parches se midió en una laptop con un i7-8565U y dio unas 3 veces más lecturas por segundo. La serie de 10 parches (rcu-free-v3) se midió en un Threadripper de 64 hilos y dio hasta 23 veces.

¿Qué es RCU?

RCU (Read-Copy-Update) es un mecanismo del kernel que permite leer datos compartidos sin tomar locks ni contadores atómicos. Las estructuras viejas se liberan recién cuando ya no quedan lectores que puedan estar usándolas, es decir, después de un grace period.

Fuentes consultadas: Phoronix, The New Stack y DEV Community. Verificá el estado de los parches en la lista de correo del kernel antes de tomar decisiones técnicas.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting