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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-02-27 at 17:31 -0700, Mike Latimer wrote:
> On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> > After adding 2048aeec, dom0's target is lowered by the required amount (e.g.
> > 64GB), but as dom0 cannot balloon down fast enough,
> > libxl_wait_for_memory_target returns -5, and the domain create fails
>     (wrong return code - libxl_wait_for_memory_target actually returns -3)
> 
> With libxl_wait_for_memory_target return code corrected (2048aeec), debug 
> messages look like this:
> 
> Parsing config from sles12pv
>  DBG: start freemem loop
>  DBG: free_memkb = 541976, need_memkb = 67651584 (rc=0)
>  DBG: dom0_curr_target = 2118976472, set_memory_target = -67109608 (rc=1)
>  DBG: wait_for_free_memory = 67651584 (rc=-5)
>  DBG: wait_for_memory_target (rc=-3)
> failed to free memory for the domain
> 
> After failing, dom0 continues to balloon down by the requested amount 
> (-67109608), so a subsequent startup attempt would work.
> 
> My original fix (2563bca1) was intended to continue looping in freem until 
> dom0 
> ballooned down the requested amount. However, this really only worked without 
> 2048aeec, as wait_for_memory_target was always returning 0. After Stefano 
> pointed out this problem, commit 2563bca1 can still be useful - but seems 
> less 
> important as ballooning down dom0 is where the major delays are seen.
> 
> The following messages show what was happening when wait_for_memory_target 
> was 
> always returning 0. I've narrowed it down to just the interesting messages:
> 
> DBG: free_memkb = 9794852, need_memkb = 67651584 (rc=0)
> DBG: dom0_curr_target = 2118976464, set_memory_target = -67109596 (rc=1)
> DBG: dom0_curr_target = 2051866868, set_memory_target = -57856732 (rc=1)
> DBG: dom0_curr_target = 1994010136, set_memory_target = -50615004 (rc=1)
> DBG: dom0_curr_target = 1943395132, set_memory_target = -43965148 (rc=1)
> DBG: dom0_curr_target = 1899429984, set_memory_target = -37538524 (rc=1)
> DBG: dom0_curr_target = 1861891460, set_memory_target = -31560412 (rc=1)
> DBG: dom0_curr_target = 1830331048, set_memory_target = -25309916 (rc=1)
> DBG: dom0_curr_target = 1805021132, set_memory_target = -19514076 (rc=1)
> DBG: dom0_curr_target = 1785507056, set_memory_target = -13949660 (rc=1)
> DBG: dom0_curr_target = 1771557396, set_memory_target = -8057564 (rc=1)
> DBG: dom0_curr_target = 1763499832, set_memory_target = -1862364 (rc=1)
> 
> The above situation is no longer relevant, but the overall dom0 target 
> problem 
> is still an issue. It now seems rather obvious (hopefully) that the 10 second 
> delay in wait_for_memory_target is not sufficient. Should that function be 
> modified to monitor ongoing progress and continue waiting as long as progress 
> is being made?

You mean to push the logic currently in freemem to keep going so long as
there is progress being made down into libxl_wait_for_memory_target?
That seems like a good idea.

Only problem would be API compatibility for older versions. Given the
comment in libxl.h above this function perhaps we can sweep this under
the carpet, and say the timeout is now the time to wait without progress
being made.

Ian.

> 
> Sorry for the long discussion to get to this point. :(
> 
> -Mike
> 
> 



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