Edera ha publicado la cuarta entrega de su serie técnica sobre NUMA en Xen, en la que detalla cómo cerró la brecha de E/S del dom0 en máquinas con memoria no uniforme. El trabajo aborda un problema de raíz: en hosts multi-socket, el código estándar de Xen asigna a dom0 toda la memoria de los nodos de menor dirección física, dejando el resto sin páginas propias. En un host de 128 GiB con 8 nodos y dom0_mem al 35 %, dom0 absorbía el 100 % de la RAM de los nodos 0-2 y el 0 % de los nodos 3-7.
La solución de Edera sustituye ese reparto secuencial por uno proporcional, repartiendo la memoria de dom0 entre todos los nodos según su cuota de RAM física mediante un algoritmo tipo Bresenham. A partir de ahí, el equipo extendió a dom0 la síntesis de topología NUMA que Xen ya ofrece para domU: tablas SRAT y SLIT coherentes con el host y x2APIC IDs en CPUID codificados de acuerdo con la misma maquinaria. Para que la síntesis tenga sentido, dom0 debe ser PVH, arrancar con dom0_vcpus_pin=1, contar con un vCPU por cada pCPU y ejecutarse en un host con más de un nodo NUMA.
El resultado es que utilidades como numactl -H dentro de dom0 muestran por primera vez la topología real, los demonios de almacenamiento y los runtimes de contenedores la ven también, y el balanceo NUMA automático del kernel puede actuar sobre una base fiel. Edera destaca que esto evita que los pods no aislados que conviven con zonas selladas en el mismo host paguen una penalización oculta al pasarse a Xen. La entrada cierra con un apunte sobre un error de colocación de memoria en su propio toolstack, detectado solo bajo un benchmark de ancho de banda.