From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: freemem-slack and large memory environments Date: Fri, 27 Feb 2015 10:17:40 +0000 Message-ID: <1425032260.14641.141.camel@citrix.com> References: <4321015.nah3j6dvJq@mlatimer1.dnsdhcp.provo.novell.com> <4455263.R3RfNP62EE@mlatimer1.dnsdhcp.provo.novell.com> <1424972841.14641.110.camel@citrix.com> <3240823.yXxKDP4SRd@mlatimer1.dnsdhcp.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3240823.yXxKDP4SRd@mlatimer1.dnsdhcp.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mike Latimer Cc: ian.jackson@eu.citrix.com, Stefano Stabellini , wei.liu2@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2015-02-26 at 13:38 -0700, Mike Latimer wrote: > (Sorry for the delayed response, dealing with ENOTIME.) > > On Thursday, February 26, 2015 05:47:21 PM Ian Campbell wrote: > > On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote: > > > > > rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0); > > > > I think so. In essence we just need to update need_memkb on each > > iteration, right? > > Not quite... Indeed, looking again I see that the 1 there means "relative", so I'm still confused about why free_memkb - need_memkb isn't the correct delta on every iteration. Is the issue that if you have a current target of, say, 15 and you wish to go to ten you would say libxl_set_memory_target(, 15 - (-5), 1, 0) i.e. libxl_set_memory_target(, -5, 1, 0) then the target would be set to 10, but if during libxl_wait_for_free_memory you only ballooned -2 and failed the target gets left at 10 but the current free is actually now 13 so next time around you say: libxl_set_memory_target(, 13 - (-3), 1, 0) i.e. libxl_set_memory_target(, -3, 1, 0) and the target now becomes 10-3 == 7, rather than 13-3=10 as one might expect? > need_memkb is used in the loop to determine if we have enough > free memory for the new domain. So, need_memkb should always remain set to the > total amount of memory requested - not just the amount of change still > required. > > The easiest thing to do is set the dom0's memory target before the loop, which > is what my original patch did. It seems like there are two viable approaches here: First is to just set the target before the loop and wait (perhaps much longer) for it to be achieved. The second is to decrement the target in smaller steps and wait to reach it each time. I don't think an approach which sets a target, waits for that target to be achieved and then on partial success tries to figure out what the relative progress is and what is left to achieve and factor that into a new target request makes sense. This is all confounded by the fact that the libxl_wait_for_free_* functions have a barking interface. I've just seen this comment right above: /* * WARNING * This memory management API is unstable even in Xen 4.2. * It has a numer of deficiencies and we intend to replace it. * * The semantics of these functions should not be relied on to be very * coherent or stable. We will however endeavour to keep working * existing programs which use them in roughly the same way as libxl. */ Given that I think that we should feel free, if necessary, to deprecate the current interface and replace it with one which is actually usable. Whatever that might mean. Ian.