July 24, 2026
NUMA drama, comment-section chaos
Making Xen's dom0 I/O path NUMA aware
Xen tries to fix a sneaky slowdown, but the comments ask why Xen still exists
TLDR: Xen fixed a major hidden slowdown by spreading its control system’s memory across the whole machine instead of piling it into one area. Readers were less obsessed with the patch than with two spicy questions: why Xen still matters at all, and why the article felt like an AI-written maze.
This was supposed to be a deep dive into how Xen, the software that lets one computer run many virtual machines, is cleaning up a hidden performance mess on big multi-processor servers. The core reveal: the system’s main control layer, called dom0, had its memory sitting in the wrong places, so work kept bouncing around the machine inefficiently. The fix spreads memory more evenly and teaches Xen to understand the machine’s layout better, which should mean faster input/output and fewer weird slowdowns.
But let’s be honest: the real fireworks were in the reactions. One commenter came in swinging with the bluntest possible vibe check: why are we even using Xen when KVM exists? That instantly turned the post from “careful engineering write-up” into a mini existential crisis for the platform. Another reader dragged the article’s writing style itself, basically saying it reads like an LLM wandered into a hedge maze and never found the exit. Ouch.
So the mood was a delicious mix of respect for the engineering, confusion over why the project matters in 2026, and low-key roasting of the article’s storytelling. The accidental comedy? A post about fixing where memory lives ended up triggering a debate over whether Xen should still have a home at all. Classic internet: one side is carefully rebuilding the engine, the other is yelling, “Cool, but why not buy a different car?”
Key Points
- •The article says Xen dom0 I/O performance on NUMA hosts was affected by missing NUMA metadata on foreign-mapped pages, poorly placed kthreads, and incomplete topology information.
- •A prerequisite problem was that stock Xen assigned dom0 memory in physical address order from the E820 map, concentrating dom0-owned memory on low-address NUMA nodes.
- •The article gives an example of a 128 GiB, 8-node host with `dom0_mem=35%`, where nodes 0-2 were mostly consumed by dom0 and nodes 3-7 had no dom0 pages.
- •The described fix replaces in-order dom0 memory assignment with a two-pass proportional allocation method using Bresenham-style arithmetic so dom0 memory is spread across all host nodes.
- •The article says accurate NUMA awareness in Xen domains requires consistent SRAT, SLIT, and x2APIC/CPUID data; upstream Xen synthesizes SRAT and SLIT for some vNUMA configurations but not x2APIC IDs.