|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ballooning interface
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? > >> 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. Sorry if I wasn't clear enough here: the guest shouldn't rewrite the target balloon size, but e.g. memory/vnode<n>/balloon-size. > >>>>>> 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. I think so, yes. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |