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.
The other case is where management tools are creating VMs. In this
case, it's probably better to use numactl as an external tool because
then it keeps things consistent wrt CPU pinning.
There's also a good argument for not introducing CPU pinning directly
to QEMU. There are multiple ways to effectively do CPU pinning. You
can use taskset, you can use cpusets or even something like libcgroup.
If you refactor the series so that the libnuma patch is the very last
one and submit to qemu-devel, I'll review and apply all of the first
patches. We can continue to discuss the last patch independently of
the first three if needed.
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 have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
