Re: freemem-slack and large memory environments

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

>>> On 02.03.15 at 13:13, <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 2 Mar 2015, Jan Beulich wrote:
>> >>> 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.
> 
> There is no way for Dom0 to notify Xen and/or libxl that ballooning is
> completed. There is no choice but to wait. We could make the wait time
> unlimited (after all arbitrarily large requests need arbitrarily large
> wait times), but do we really want that?

That's why almost everyone else seem to agree that waiting as
long as there is progress being made is the right approach.

> Of course users could just use dom0_mem and get down with it.

I don't think we should make this a requirement for correct
operation.

Jan