[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [RFC] Xen NUMA strategy



Hi, Anthony

>>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.
>
It sounds good.

>>
>>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.
>
I got it. It sounds cool.

>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.
>
I also think so.

Best Regards,

Akio Takebe


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.