Hacker News
Making Xen's dom0 I/O path NUMA aware
unixhero
|next
[-]
twoodfin
|next
|previous
[-]
Say what you will about—or try to prompt out—their rhetorical flourishes, they can link together a series of background, observations, implications, …
But man, they are hopeless at crafting a high-level narrative. It’s one big hedge maze of a garden path:
This part makes good on that - and along the way it covers two things we did not plan to fix. One we hit before the real work could start: dom0's own memory placement was so skewed that synthesising a topology for dom0 without fixing it first would have been an exercise in lying to a kernel that had no memory to back the lie with. That one is a prerequisite, not a detour - everything else in this part is built on top of it. The other we hit after the work was nominally done: a memory-placement bug in our own toolstack that had been silently broken for as long as multi-vnode vNUMA had existed in our tree, and only ever surfaced under a memory-bandwidth benchmark. That one is the genuine detour, and it waits until the end.
Let's start with the prerequisite.
Where are we going here and why?!