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

[Avi Kivity <avi@redhat.com>]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Andre Przywara wrote:
>>
>>> Any other useful commands for the monitor? Maybe (temporary) VCPU 
>>> migration without page migration?
>>
>> Right now vcpu migration is done externally (we export the thread IDs 
>> so management can pin them as it wishes).  If we add numa support, I 
>> think it makes sense do it internally as well.  I suggest using the 
>> same syntax for the monitor as for the command line; that's simplest 
>> to learn and to implement.
>
> I see no compelling reason to do cpu placement internally.  It can be 
> done quite effectively externally.
>
> Memory allocation is tough, but I don't think it's out of reach.  
> Looking at the numactl man page, you can do:
>
> numactl  --offset=1G  --length=1G --membind=1 --file /dev/shm/A --touch
>       Bind the second gigabyte in the tmpfs file /dev/shm/A to node 1.
>
>
> Since we can already create VM's with the -mem-path argument, if you 
> create a 2GB guest and want it to span two numa nodes, you could do:
>
> numactl  --offset=0G  --length=1G --membind=0 --file /dev/shm/A --touch
> numactl  --offset=1G  --length=1G --membind=1 --file /dev/shm/A --touch
>
> And then create the VM with:
>
> qemu-system-x86_64 -mem-path /dev/shm/A -mem 2G ...
>
> What's best about this approach, is that you get full access to what 
> numactl is capable of.  Interleaving, rebalancing, etc.

It looks horribly difficult and unintuitive.  It forces you to use 
-mem-path (which is an abomination; the only reason it lives is that we 
can't allocate large pages with it).

-- 
error compiling committee.c: too many arguments to function