Re: [PATCH 0/3] v2: KVM-userspace: add NUMA support for guests

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> In the event that the VM is larger than a single node, if a user is 
>> creating it via qemu-system-x86_64, they're going to either not care 
>> at all about NUMA, or be familiar enough with the numactl tools that 
>> they'll probably just want to use that.  Once you've got your head 
>> around the fact that VCPUs are just threads and the memory is just a 
>> shared memory segment, any knowledgable sysadmin will have no problem 
>> doing whatever sort of NUMA layout they want.
>>
>
> The vast majority of production VMs will be created by management tools.

I agree.

> We need libnuma integrated in qemu.  Using numactl outside of qemu 
> means we need to start exposing more and more qemu internals 
> (vcpu->thread mapping, memory in /dev/shm, phys_addr->ram_addr 
> mapping) and lose out on optimization opportunities (having multiple 
> numa-aware iothreads, numa-aware kvm mmu).  It also means we cause 
> duplication of the numa logic in management tools instead of 
> consolidation in qemu.

I think it's the opposite.  Integrating libnuma in QEMU means 
duplication of numactl functionality in QEMU.  What you'd really want, I 
think, is to be able to use numactl but say -qemu-guest-memory-offset 1G 
-qemu-guest-memory-size 1G.

The /dev/shm approximates that pretty well.  Also, the current patches 
don't do the most useful thing, they don't use provide an interface for 
dynamically changing numa attributes.

But, as I said, if there's agreement that we should bake this into QEMU, 
then so be it.  But let's make this a separate conversation than the 
rest of the patches.

Regards,

Anthony Liguori