Re: [Xen-devel] freemem-slack and large memory environments

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 27 Feb 2015, Ian Campbell wrote:
> 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.

The reason for the loop is not to make the memory decrease request more
digestible for dom0 or coping with errors. The loop tries to handle
scenarios were the freed memory is not available to us somehow.
This is a more wordy explanation of it:

  get free memory
  is it enough? if so, return, otherwise continue
  set dom0 memory target = current - need
  is there enough memory now? if so, return, otherwise continue
  has dom0 actually reached his target? If so, loop again (who stole the 
memory?), otherwise fail (dom0 is busy)

This is consistent with Mike's logs: the memory is freed by dom0 but it
is not available somehow. Maybe XenD is running? Another guest is
ballooning up at the same time?


> This is all confounded by the fact that the libxl_wait_for_free_*
> functions have a barking interface.

That is true


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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel