>We may need to write something about guest NUMA in guest configuration
file.
>For example, in guest configuration file;
>vnode = <a number of guest node>
>vcpu = [<vcpus# pinned into the node: machine node#>, ...]
>memory = [<amount of memory per node: machine node#>, ...]
>
>e.g.
>vnode = 2
>vcpu = [0-1:0, 2-3:1]
>memory = [128:0, 128:1]
>
>If we setup vnode=1, old OSes should work fine.
This is something we need to do.
But if user forget to configure guest NUMA in guest configuration file.
Xen needs to provide an optimized guest NUMA information based on
current workload on physical machine.
We need provide both, user configuration can override default
configuration.
>
>And almost OSes read NUMA configuration only at booting and CPU/memory
>hotplug.
>So if xen migrate vcpu, xen has to occur hotpulg event.
Guest should not know the vcpu migration, so xen doesn't trigger hotplug
event to guest.
Maybe we should not call it vcpu migration; we can call it vnode
migration.
Xen (maybe dom0 application) needs to migrate vnode ( include vcpus and
memorys) from a physical node to another physical node. The guest NUMA
topology is not changed, so Xen doesn't need to inform guest of the
vnode migration.
>It's costly. So pinning vcpu to node may be good.
Agree
>I think basicaly pinning a guest into a node is good.
>If the system becomes imbalanced, and we absolutely want
>to migration a guest, then xen temporarily migrate only vcpus,
>and we abandon the performance at that time.
As I mentioned above, it is not temporary migration. And it will not
impact performance, (it may impact the performance only at the process
of vnode migration)
And I think imbalanced is rare in VMM if user doesn't create and destroy
domain frequently. And VMs on VMM are far less than applications on
machine.
- Anthony
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel