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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
