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
--
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
