| ▲ | Making Xen's dom0 I/O path NUMA aware(edera.dev) | |||||||||||||
| 24 points by virtio_vixen 2 days ago | 4 comments | ||||||||||||||
| ▲ | unixhero 3 hours ago | parent | next [-] | |||||||||||||
Why is Xen a thing when we have great and free KVM virtualization? Honest and dumb question. | ||||||||||||||
| ||||||||||||||
| ▲ | twoodfin 2 hours ago | parent | prev [-] | |||||||||||||
This article is a great example of the limits of LLM technical writing. 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?! | ||||||||||||||