WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/5] [POST-4.0]: RFC: HVM NUMA guest support

Cui, Dexuan wrote:
Andre Przywara wrote:
Cui, Dexuan wrote:
Hi Andre,  will you re-post your patches?
Yes, I will do in the next days. I plan to add the missing automatic
assignment patch before posting.
Glad to know this.
BTW: To support PV NUMA, on this Monday, Dulloor posted some paches that change 
libxc and the hypervisor, too.
Yes, I saw them. I am about to look at them more thoroughly. Will get back to you later on this.

<skip>
And we should add one more option "uniform_nodes" -- this boolean
option's default value can be True, meaning if we can't construct
uniform nodes to guest(e.g., on the related host node, no enough
memory as expected can be allocated to the guest),  the guest
creation should fail. This option is useful to users who want
predictable guest performance.
I agree that we need to avoid missing user influence, although I'd
prefer to have the word "strict" somewhere in this name. As I wrote in
one my earlier mails, I'd opt for a single option describing the
policy, the "strict" meaning could be integrated in there:
numa_policy="strict|uniform|automatic|none|single|..."
Hi Andre,
I think this looks too complex for the first simple implementation and it's 
very likely a real user will be bewildered. :-)
I think ideally we can have 2 options:
guest_nodes=n
uniform_nodes=True|False (the default is True)
I agree on the guest_nodes, but I want to avoid a bunch of "single bit" options that we need to carry on later. Lets introduce a numa_policy option and only implement the words we need for now, e.g. "strict" (equivalent to "uniform_nodes=True") and "automatic" (aka "uniform_nodes=False"). The list I gave above was just a quick example of _possible_ words, it was neither exhaustive or non-redundant.

Regards,
Andre.

--
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712


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