El 24 de octubre, Phoronix informó de que se había enviado una propuesta para Linux 7.4 que cambia cómo memblock localiza regiones de memoria. El parche de Tarun Sahu sustituye barridos lineales por búsqueda binaria en dos funciones y apunta a reducir el tiempo de recuperación de memoria en cargas muy fragmentadas.
Qué hace memblock durante el arranque
memblock gestiona la memoria física al principio del arranque de Linux, antes de que se ponga en marcha el asignador completo de páginas. Por eso, el cambio se centra en una etapa temprana de inicialización del kernel, no en la ejecución habitual de aplicaciones.
Cómo cambia la búsqueda en memblock
El parche de Sahu modifica memblock_add_range() y memblock_isolate_range(), dentro de mm/memblock.c. En ambas funciones, una búsqueda binaria de límite inferior localiza la primera región cuyo final supera la dirección de inicio buscada. Así evita recorrer las regiones desde la primera en cada operación.
El autor describe los barridos repetidos como un caso de complejidad O(N²) cuando la memoria está muy fragmentada. La búsqueda propuesta reduce la complejidad al peor caso O(N log N), y a O(N) en inserciones secuenciales. Sahu señaló que los barridos lineales pueden ser eficientes en listas pequeñas; el problema que aborda el parche son las listas grandes y fragmentadas. El código también se usa durante la conexión en caliente de memoria.
Qué mide el resultado de KHO
Para un caso de Kernel Handover (KHO) con unas 393.000 páginas, Sahu informó de una reducción del tiempo de recuperación de unos 268 segundos a unos 50 milisegundos. Es el resultado atribuido al autor del parche para esa carga concreta.
| Medición y escenario | Antes del cambio | Después del cambio |
| Recuperación de memoria KHO, unas 393.000 páginas | Unos 268 segundos | Unos 50 milisegundos |
Qué registró otra carga
Dongli Zhang describió una prueba distinta en un sistema de 32 CPU y un nodo, con THP en never y páginas de 4K. En los registros que publicó, el intervalo entre los marcadores mem auto-init y SLUB fue de 38,355755 segundos antes de aplicar el parche y de 0,264273 segundos en las pruebas posteriores. Esos tiempos corresponden a ese tramo de los registros de arranque de su carga.
