Re: freemem-slack and large memory environments

["Jan Beulich" <JBeulich@suse.com>]

>>> On 02.03.15 at 11:12, <stefano.stabellini@eu.citrix.com> wrote:
> 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?

No fixed timeout will ever be enough for arbitrarily large requests.

Jan