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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 26 Feb 2015, Mike Latimer wrote:
> On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > > There is still one aspect of my original patch that is important. As the
> > > code currently stands, the target for dom0 is set lower during each
> > > iteration of the loop. Unless only one iteration is required, dom0 will
> > > end up being set to a much lower target than is actually required.
> > 
> > Is this because some sort of slack is applied once per iteration rather
> > than once at the start or is it something else?
> 
> No - the slack reservation just complicated the request by (potentially) 
> requiring more free memory than domU initially requested.
> 
> With or without slack, the central loop in tools/libxl/xl_cmdimpl.c:freemem, 
> frees memory for domU by lowering the memory target for dom0. However, this 
> is 
> not a single request (e.g. free 64GB for domX), rather the memory target for 
> dom0 is set lower during every iteration through:
> 
>    rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0);
> 
> This causes dom0's memory target to be lowered by the needed amount during 
> every iteration of the loop. In practice, this causes the first request to 
> lower dom0's target by the full amount (e.g. -64GB), and subsequent 
> iterations 
> further lower dom0's target by however much memory that still appears to be 
> required (e.g. three iterations of the loop might lower dom0's target by 
> -25GB, then -25GB, for a total of dom0 ballooning down 114GB). The issue 
> itself is due to the loop ignoring the fact that the original request set 
> dom0's target to the correct amount, but the ballooning has not completed.

What is the return value of libxl_set_memory_target and
libxl_wait_for_free_memory in that case? Isn't it just a matter of
properly handle the return values?

Or maybe we just need to change the libxl_set_memory_target call to use
an absolute memory target to avoid restricting dom0 memory more than
necessary at each iteration. Also increasing the timeout argument passed
to the libxl_wait_for_free_memory call could help.


> The problem itself is easier to see when domU memory sizes are increased. As 
> mentioned before, starting a 512GB domain should guarantee that multiple 
> iterations of the loop are required, and dom0 will balloon down much further 
> than the required 512GB.
> 
> Does this clarify the situation?



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