Re: [Xen-devel] Xen ballooning interface

[Juergen Gross <jgross@xxxxxxxx>]

On 13/08/18 16:12, Roger Pau Monné wrote:
> On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
>> Today's interface of Xen for memory ballooning is quite a mess. There
>> are some shortcomings which should be addressed somehow. After a
>> discussion on IRC there was consensus we should try to design a new
>> interface addressing the current and probably future needs.
> 
> Thanks for doing this! Memory accounting is quite messy at the moment
> :(.
> 
> [...]
>> Open questions
>> --------------
>> Should we add memory size information to the memory/vnode<n> nodes?
>>
>> Should the guest add information about its current balloon sizes to the
>> memory/vnode<n> nodes (i.e. after ballooning, or every x seconds while
>> ballooning)?
>>
>> Should we specify whether the guest is free to balloon another vnode
>> than specified?
> 
> What if the guest simply doesn't support NUMA and doesn't know
> anything about nodes?

Okay, that's a rather good answer to this question. :-)

>> Should memory hotplug (at least for PV domains) use the vnode specific
>> Xenstore paths, too, if supported by the guest?
> 
> Is extra memory hotplug going to set:
> 
> memory/vnode<n>/target-balloon-size = -1000
> 
> In order to tell the guest it can hotplug past the boot time amount of
> memory?

Interesting idea.

> 
>> Any further thoughts on this?
> 
> Isn't this just moving the memory accounting problem to another piece
> of software?
> 
> Currently as you say there's a difference between the xenstore target
> and the guest memory map, because some memory is used by the firmware.
> In order to solve this the toolstack won't provide an absolute memory
> target but instead a relative one to the guest that contains the
> balloon size.
> 
> But the toolstack interface (xl) still uses mem-set which is an
> absolute value. How is the toolstack going to accurately calculate the
> balloon size without knowing the extra memory used by the firmware?

mem-set will make use of the current allocation the tools know about and
add/subtract the difference to the new value to/from the target balloon
size. I don't think firmware will eat away memory when the guest OS is
already running. :-)

The main difference to today's situation is that the same component
which did the initial calculation how much memory should be allocated is
doing the math in case of ballooning now. So no guesswork any longer.


Juergen


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