Xen dom0 I/O路径如何支持NUMA
Making Xen's dom0 I/O path NUMA aware
在Xen虚拟化环境中，dom0的内存分配长期存在NUMA感知盲区，导致多节点主机上性能严重失衡。我们首先修复了dom0内存分布不均的问题，通过比例分配确保每个NUMA节点都有dom0内存。接着，我们为dom0合成了完整的NUMA拓扑信息，包括SRAT、SLIT和x2APIC ID，使其能像普通Linux系统一样感知真实硬件结构。这一改进让dom0内的存储守护进程和容器运行时都能利用NUMA优化，甚至让未沙箱化的普通容器在Xen主机上也能获得与裸机相当的性能。
让dom0具备NUMA感知能力，填补了性能差距：那些留在dom0中的容器，终于能像在裸机上一样看到它们应有的拓扑结构。
HN 评论区
10- unixhero
既然我们有强大且免费的 KVM 虚拟化方案，Xen 为什么还存在？这是个诚实又有点傻的问题。
- twoodfin
这篇文章是 LLM 技术写作局限性的绝佳例子。
不管你怎么说——或者怎么提示——它们那些修辞 flourish，能把一系列背景、观察、推论……串联起来。
但天哪，它们在构建高层叙事方面简直 hopeless。这就像一座巨大的树篱迷宫，全是花园小径：
这部分兑现了那部分——同时它还涵盖了两个我们原本没计划要修复的问题。其中一个是在真正工作开始前就遇到的：dom0 自身的内存放置偏差太大，以至于如果不先修复它，就为 dom0 合成拓扑结构，那简直是在对一个没有内存来支撑谎言的内核撒谎。这是前提条件，不是绕路——这一部分的其他所有内容都建立在此基础上。另一个是在工作名义上完成后遇到的：我们自己的工具栈中有一个内存放置 bug，自从我们的代码树中存在多 vnode vNUMA 以来，它就一直静默地处于损坏状态，而且只在内存带宽基准测试中才会暴露出来。那才是真正的绕路，它被留到了最后。
让我们从前提条件开始。
我们要去哪里，为什么要去？！