Re: [Xen-devel] Xen ballooning interface

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

> This results in a balloon size per node.
> 
> There is still the option to let the guest adjust the per node balloon
> sizes after reaching the final memory size or maybe during the process
> of ballooning at a certain rate.

I'm probably increasingly confused: Shouldn't, for whichever value
in xenstore, there be a firm determination of which single party is
supposed to modify a value? Aiui the intention is for the (target)
balloon size to be set by the tools.

>>>>> Any further thoughts on this?
>>>>
>>>> The other problem we've always had was that address information
>>>> could not be conveyed to the driver. The worst example in the past
>>>> was that 32-bit PV domains can't run on arbitrarily high underlying
>>>> physical addresses, but of course there are other cases where
>>>> memory below a certain boundary may be needed. The obvious
>>>> problem with directly exposing address information through the
>>>> interface is that for HVM guests machine addresses are meaningless.
>>>> Hence I wonder whether a dedicated "balloon out this page if you
>>>> can" mechanism would be something to consider.
>>>
>>> Isn't this a problem orthogonal to the one we are discussing here?
>> 
>> Yes, but I think we shouldn't design a new interface without
>> considering all current shortcomings.
> 
> I don't think the suggested interface would make it harder to add a way
> to request special pages to be preferred in the ballooning process.

Address and (virtual) node may conflict with one another. But I
think we've meanwhile settled on the node value to only be a hint
in a request.

Jan



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