Re: freemem-slack and large memory environments

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-02-26 at 13:38 -0700, Mike Latimer wrote:
> (Sorry for the delayed response, dealing with ENOTIME.)
> 
> On Thursday, February 26, 2015 05:47:21 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
> >
> > >    rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0);
> >
> > I think so. In essence we just need to update need_memkb on each
> > iteration, right?
> 
> Not quite...

Indeed, looking again I see that the 1 there means "relative", so I'm
still confused about why free_memkb - need_memkb isn't the correct delta
on every iteration.

Is the issue that if you have a current target of, say, 15 and you wish
to go to ten you would say

	libxl_set_memory_target(, 15 - (-5), 1, 0)
i.e.
	libxl_set_memory_target(, -5, 1, 0)

then the target would be set to 10, but if during
libxl_wait_for_free_memory you only ballooned -2 and failed the target
gets left at 10 but the current free is actually now 13 so next time
around you say:

	libxl_set_memory_target(, 13 - (-3), 1, 0)
i.e.
	libxl_set_memory_target(, -3, 1, 0)

and the target now becomes 10-3 == 7, rather than 13-3=10 as one might
expect?

>   need_memkb is used in the loop to determine if we have enough 
> free memory for the new domain. So, need_memkb should always remain set to the 
> total amount of memory requested - not just the amount of change still 
> required.
> 
> The easiest thing to do is set the dom0's memory target before the loop, which 
> is what my original patch did.

It seems like there are two viable approaches here:

First is to just set the target before the loop and wait (perhaps much
longer) for it to be achieved.

The second is to decrement the target in smaller steps and wait to reach
it each time.

I don't think an approach which sets a target, waits for that target to
be achieved and then on partial success tries to figure out what the
relative progress is and what is left to achieve  and factor that into a
new target request makes sense.

This is all confounded by the fact that the libxl_wait_for_free_*
functions have a barking interface. I've just seen this comment right
above:

/*
 * WARNING
 * This memory management API is unstable even in Xen 4.2.
 * It has a numer of deficiencies and we intend to replace it.
 *
 * The semantics of these functions should not be relied on to be very
 * coherent or stable.  We will however endeavour to keep working
 * existing programs which use them in roughly the same way as libxl.
 */

Given that I think that we should feel free, if necessary, to deprecate
the current interface and replace it with one which is actually usable.
Whatever that might mean.

Ian.