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:21:05 +0000 Message-ID: <1425032465.14641.145.camel@citrix.com> References: <4321015.nah3j6dvJq@mlatimer1.dnsdhcp.provo.novell.com> <10963636.bJrCl8V3JU@mlatimer1.dnsdhcp.provo.novell.com> <1614208.FAtanMl2ZW@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: <1614208.FAtanMl2ZW@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: wei.liu2@citrix.com, Stefano Stabellini , ian.jackson@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2015-02-26 at 16:30 -0700, Mike Latimer wrote: > On Thursday, February 26, 2015 01:45:16 PM Mike Latimer wrote: > > On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote: > > > What is the return value of libxl_set_memory_target and > > > libxl_wait_for_free_memory in that case? Isn't it just a matter of > > > properly handle the return values? > > > > The return from libxl_set_memory_target is 0, as the assignment works just > > fine. I don't have the return from libxl_wait_for_free_memory in my notes, > > so I'll spin up another test and track that down. > > I slightly misspoke here... In my testing, the returns are actually: > > libxl_set_memory_target = 1 > libxl_wait_for_free_memory = -5 > libxl_wait_for_memory_target = 0 > Note - libxl_wait_for_memory_target is confusing, Further to the comment I just made WRT this source comment: /* * 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. */ I think we should feel free to introduce a new interface which has semantics which we can actually work with. IOW > as rc can be set > to ERROR_FAIL, but the function returns 0 anyway (unless an error > is encountered earlier.) I guess this just means we need to continue > to wait... Do something sensible so there is no more guessing. I'm not sure yet what "sensible" would be. One approach to fixing this might be when the replacenent for libxl_wait_for_memory_target fails it sets the target to whatever was actually achieved, such that further calculations involving free_memkb and the overall target will still be valid. Or we could move the "progress is being made" logic currently in xl's freemem down into the wait_for_memory_target replacement so it hopefully has more information available to it in order to make better decisions about the timeouts. Ian.