Andre Przywara wrote:
> 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").
I think the word "strict" or "automatic" is too obscure to the user.
We'd better use an unambiguous name.
Thanks,
-- Dexuan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home