Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding

[Alexander Graf]

On 29.10.2011, at 20:45, Bharata B Rao wrote:

> Hi,
> 
> As guests become NUMA aware, it becomes important for the guests to
> have correct NUMA policies when they run on NUMA aware hosts.
> Currently limited support for NUMA binding is available via libvirt
> where it is possible to apply a NUMA policy to the guest as a whole.
> However multinode guests would benefit if guest memory belonging to
> different guest nodes are mapped appropriately to different host NUMA nodes.
> 
> To achieve this we would need QEMU to expose information about
> guest RAM ranges (Guest Physical Address - GPA) and their host virtual
> address mappings (Host Virtual Address - HVA). Using GPA and HVA, any external
> tool like libvirt would be able to divide the guest RAM as per the guest NUMA
> node geometry and bind guest memory nodes to corresponding host memory nodes
> using HVA. This needs both QEMU (and libvirt) changes as well as changes
> in the kernel.

Ok, let's take a step back here. You are basically growing libvirt into a 
memory resource manager that know how much memory is available on which nodes 
and how these nodes would possibly fit into the host's memory layout.

Shouldn't that be the kernel's job? It seems to me that architecturally the 
kernel is the place I would want my memory resource controls to be in.

Imagine QEMU could tell the kernel that different parts of its virtual memory 
address space are supposed to be fast on different host vcpu threads. Then the 
kernel has all the information it needs. It could even potentially migrate 
memory towards a thread, whenever the scheduler determines that it's better to 
run a thread somewhere else.

That said, I don't disagree with your approach per se. It just sounds way too 
static to me and tries to overcome shortcomings we have in the Linux mm system 
by replacing it with hardcoded pinning logic in user space.


Alex