Re: [Xen-devel] Xen ballooning interface

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.08.18 at 09:19, <jgross@xxxxxxxx> wrote:
> On 14/08/18 09:02, Jan Beulich wrote:
>>>>> On 13.08.18 at 17:44, <jgross@xxxxxxxx> wrote:
>>> On 13/08/18 17:29, Jan Beulich wrote:
>>>>>>> On 13.08.18 at 16:20, <jgross@xxxxxxxx> wrote:
>>>>> On 13/08/18 15:54, Jan Beulich wrote:
>>>>>>>>> On 13.08.18 at 15:06, <jgross@xxxxxxxx> 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.

Jan



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