Hay operaciones del kernel que solo se notan cuando la máquina es enorme. Una de ellas, la búsqueda de regiones de memoria física que el sistema hace en pleno arranque, se comía alrededor de 268 segundos cuando la memoria llegaba muy fragmentada. La serie de cambios de memblock enviada para Linux 7.4 el 24 de octubre de 2026 deja esa misma tarea en torno a 50 milisegundos y el mensaje del parche firmado por Tarun Sahu, ingeniero de Google.
La causa era sencilla de contar y algo vergonzosa de explicar. memblock es el asignador que reserva y libera memoria física antes de que exista el asignador de páginas normal, y llevaba años recorriendo su lista de regiones candidatas una por una en lugar de dividirla por la mitad. La búsqueda lineal solo se vuelve insoportable con mucha memoria y muchos huecos, así que el problema vivió escondido en un camino que casi nadie cronometraba.
Ese camino dejó de ser residual. La entrega de memoria entre kernels, conocida como Kernel Handover o KHO, deja miles de folios dispersos que memblock debe encontrar después de un relevo en caliente, y el mismo ciclo de fusión ha aflojado un segundo cuello con los workqueues. Las cifras salen de pruebas publicadas por el ecosistema de desarrollo, no de un portátil doméstico, y esa diferencia importa para leerlas con criterio.
De la búsqueda lineal a la binaria
El cambio vive en dos funciones de `mm/memblock.c`, memblock_add_range y memblock_isolate_range, que hasta ahora buscaban el hueco adecuado recorriendo la lista de regiones desde el principio. Sahu detectó que ese recorrido lineal bastaba para hundir el peor caso.
El parche lo sustituye por una búsqueda binaria sobre una lista que ya está ordenada. La complejidad baja a O(N log N) en el peor caso y se queda en O(N) cuando las inserciones llegan en orden, que es el camino habitual en un arranque sin sobresaltos.
El mensaje del parche lo resume con una frase seca: la búsqueda binaria recorta la recuperación de memoria de KHO de unos 268 segundos a unos 50 milisegundos, y el peor caso pasa a crecer con N log N en vez de arrastrar un recorrido completo por cada inserción.
¿Dónde se atasca un kernel que arranca?
El escenario que destapó la cifra no es un arranque cualquiera. KHO transfiere la memoria de un kernel en marcha a otro sin reiniciar la máquina, y esa operación la usan el Live Update Orchestrator y herramientas parecidas para aplicar actualizaciones sin cortar el servicio. Con la memoria troceada en miles de folios sueltos, memblock tiene que localizar cada región válida entre un bosque de huecos, uno por cada folio que quedó disperso.
Un portátil con 16 GB no va a notar este cambio, porque su mapa de memoria es pequeño y la búsqueda lineal termina antes de que el usuario vea el logo del arranque.
El beneficio aparece en servidores con mucha RAM, en el arranque de máquinas virtuales encadenadas y en cualquier operación que obligue a recorrer el mapa físico entero con la memoria fragmentada. La cifra de 268 segundos describe ese extremo, no la media de un escritorio.
La memoria es, además, el recurso que más discusiones abre este otoño en el kernel. La escasez de DRAM ha devuelto a la mesa el debate sobre pilas más pequeñas por tarea, donde cada kilobyte cuenta en flotas con millones de hilos. Trabajar mejor el mapa físico encaja en esa misma lógica de ahorro.
Workqueues, el otro cuello que se afloja
La otra mitad del acelerón llegó un día antes, con los workqueues como protagonistas, en el tirón que cambió el recorrido de las colas. Un workqueue es la cola con la que el kernel aplaza trabajo para ejecutarlo después en un hilo aparte, y vaciarla exigía visitar una cola por cada CPU posible, aunque solo unas pocas hubieran recibido trabajo desde el último vaciado.
Tejun Heo firmó el cambio que limita el recorrido a las colas usadas desde el flush anterior. En una máquina de 192 CPU repartidas en dos nodos, vaciar una workqueue inactiva ligada a CPU pasó de 40.000 a 4,2 millones de operaciones por segundo, y la no ligada a CPU saltó de 450.000 a 4,3 millones, según las cifras que el propio autor incluyó en el mensaje del commit.
El caso que motivó el trabajo fue más concreto. Yao Kai, ingeniero de Huawei, reportó en septiembre que la workqueue CIL de XFS, vaciada en cada log force del sistema de ficheros, gastaba hasta 64 microsegundos por flush en una máquina de 128 CPU.
Queda letra pequeña. Con todos los workqueues activos, los vaciados densos no cambian en las colas por CPU y pierden entre un 15% y un 20% en las no ligadas, un precio que los mantenedores aceptaron para que el caso frecuente deje de arrastrar un recorrido por cientos de CPU ociosas.
Las mediciones del ciclo
Las cifras que resumen el ciclo se leen mejor juntas, porque cada una mide un extremo distinto del mismo problema y ninguna promete una mejora general del sistema. Conviene fijarse en la columna de contexto antes de comparar números, ya que proceden de bancos de prueba separados.
| Cambio en Linux 7.4 |
Antes |
Después |
Contexto de la prueba |
| Recuperación de memoria de KHO en memblock |
unos 268 s |
unos 50 ms |
Fragmentación extrema, folios dispersos |
| Vaciado de workqueue inactiva por CPU |
40.000 por segundo |
4,2 millones por segundo |
Máquina de 192 CPU en dos nodos |
| Vaciado de workqueue inactiva no ligada |
450.000 por segundo |
4,3 millones por segundo |
Máquina de 192 CPU en dos nodos |
| Dieciséis hilos encolando y vaciando |
30.000 por segundo |
110.000 por segundo |
Workqueue ligada a CPU |
¿Por qué el arranque pesa más en la nube?
Nadie piensa ya en ese momento de pantalla negra antes de trabajar. En una flota de máquinas virtuales, el tiempo hasta que un proceso empieza a trabajar se paga en dinero, y las plataformas que crean instancias bajo demanda vigilan ese tramo con más atención que el rendimiento sostenido. Cada minuto que el kernel pasa ordenando su mapa físico antes de ceder el control es un minuto que no produce nada.
La actualización en caliente añade una segunda razón. Un relevo de kernel sin reinicio exige mover el estado de memoria de un kernel a otro, y ese trámite solo es viable si el traspaso se mide en milisegundos. Una pausa de cuatro minutos en mitad de un mantenimiento convierte una mejora de disponibilidad en un corte de servicio.
Una ventana abierta desde el 19 de octubre
Linux 7.4 sigue en obras y ninguno de estos parches está al alcance de un usuario. La ventana de fusión abierta el 19 de octubre acumulaba 6.753 cambios sin contar las fusiones al cierre del viernes 23, un tercio del calendario habitual. Torvalds avisó de que la semana extra de margen no le servirá para aceptar trabajo que no estuviera preparado antes de abrir la puerta.
La primera versión que se podrá probar en serio es la rc1, prevista para el 1 o el 8 de noviembre, y esa fecha arrastra la fase de estabilización y el momento en que una distribución puede planear su salto.
Hasta entonces, los tirones de memblock y workqueues son piezas de un árbol principal que se mueve a diario y que no se empaqueta para producción, así que ninguna de estas mejoras ha pasado todavía el filtro de una candidata estable.
