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

[Andre Przywara <andre.przywara@amd.com>]

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