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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 27 Feb 2015, 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?
> 
> Sorry for the long discussion to get to this point. :(

I think we need to increase the timeout passed to
libxl_wait_for_free_memory. Would 30 sec be enough?

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 53c16eb..7779350 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2222,7 +2222,7 @@ static int freemem(uint32_t domid, 
libxl_domain_build_info *b_info)
         if (rc < 0)
             return rc;
 
-        rc = libxl_wait_for_free_memory(ctx, domid, need_memkb, 10);
+        rc = libxl_wait_for_free_memory(ctx, domid, need_memkb, 30);
         if (!rc)
             return 0;
         else if (rc != ERROR_NOMEM)

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