On 14/08/18 09:34, Jan Beulich wrote:
>>>> On 14.08.18 at 09:19, <jgr...@suse.com> wrote:
>> On 14/08/18 09:02, Jan Beulich wrote:
>>>>>> On 13.08.18 at 17:44, <jgr...@suse.com> wrote:
>>>> On 13/08/18 17:29, Jan Beulich wrote:
>>>>>>>> On 13.08.18 at 16:20, <jgr...@suse.com> wrote:
>>>>>> On 13/08/18 15:54, Jan Beulich wrote:
>>>>>>>>>> On 13.08.18 at 15:06, <jgr...@suse.com> wrote:
>>>>>>>> Suggested new interface
>>>>>>>> -----------------------
>>>>>>>> Hypercalls, memory map(s) and ACPI tables should stay the same (for
>>>>>>>> compatibility reasons or because they are architectural interfaces).
>>>>>>>>
>>>>>>>> As the main confusion in the current interface is related to the
>>>>>>>> specification of the target memory size this part of the interface
>>>>>>>> should be changed: specifying the size of the ballooned area instead
>>>>>>>> is much clearer and will be the same for all guest types (no firmware
>>>>>>>> memory or magic additions involved).
>>>>>>>
>>>>>>> But isn't this backwards? The balloon size is a piece of information
>>>>>>> internal to the guest. Why should the outside world know or care?
>>>>>>
>>>>>> Instead of specifying an absolute value to reach you'd specify how much
>>>>>> memory the guest should stay below its maximum. I think this is a valid
>>>>>> approach.
>>>>>
>>>>> But with you vNUMA model there's no single such value, and nothing
>>>>> like a "maximum" (which would need to be per virtual node afaics).
>>>>
>>>> With vNUMA there is a current value of memory per node supplied by the
>>>> tools and a maximum per node can be caclulated the same way.
>>>
>>> Can it? If so, I must be overlooking some accounting done
>>> somewhere. I'm only aware of a global maximum.
>>
>> The tools set the vnuma information for the guest. How do they do this
>> without knowing the memory size per vnuma node?
> 
> That's the current (initial) size, not the maximum.

Which is the same in the current implementation:
libxl__vnuma_config_check() will fail if the memory of all vnuma nodes
won't sum up to the max memory of the domain.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to