On 06/25/10 13:06, Andre Przywara wrote: > Jes Sorensen wrote: >> On 06/24/10 13:34, Andre Przywara wrote: >> I really think it makes more sense to make QEMU aware of the NUMA setup >> as well, rather than relying on numctl to do the work outside. >> >> One thing you need to consider is what happens with migration once a >> user specifies -numa. IMHO it is acceptable to simply disable migration >> for the given guest. > Is that really a problem? You create the guest on the target with a NUMA > setup specific to the target machine. That could mean that you pin > multiple guest nodes to the same host node, but that shouldn't break > something, right? The guest part can (and should be!) migrated along > with all the other device state. I think this is still missing from the > current implementation. It may be hard to guarantee the memory layout on the target machine it may have a completely different topology. The numa bindings ought to go into the state and be checked against the target machine's state, but for instance you could be trying to bind things to node 7-8 on the first host while migration target only has 2 nodes, but plenty of memory. Or you use mode nodes on the first host than you have on the second. It's a very complicated matrix to try and match. >> PS: Are you planning on submitting anything to Linux Plumbers Conference >> about this? :) > Yes, I was planning to submit a proposal, as I saw NUMA mentioned in the > topics list. AFAIK the deadline is July 19th, right? That gives me > another week after my vacation (for which I leave in a few minutes). Excellent! yes it should still by July 19th. Enjoy your vacation! Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
