From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 0/4] fix freemem loop Date: Fri, 6 Mar 2015 09:46:44 +0000 Message-ID: <1425635204.14353.22.camel@citrix.com> References: <1425577775.14353.1.camel@citrix.com> <1425618783.5Ob3InrGpG@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: <1425618783.5Ob3InrGpG@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 , Jim Fehlig Cc: Wei Liu , Stefano Stabellini , Ian Jackson , xen-devel@lists.xensource.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2015-03-05 at 21:08 -0700, Mike Latimer wrote: > On Thursday, March 05, 2015 05:49:35 PM Ian Campbell wrote: > > On Tue, 2015-03-03 at 11:08 +0000, Stefano Stabellini wrote: > > > Hi all, > > > > > > this patch series fixes the freemem loop on machines with very large > > > amount of memory, where the current wait time is not enough. > > > > > > In order to be able to handle arbitrarly large amount of ram, we > > > implement in libxl_wait_for_memory_target a policy of waiting until dom0 > > > is making progress. > > > > What is the impact of the libxl API change made here on other callers, > > in particular libvirt? I should have CCd Jim when I asked the question. Now done. > This change will have one interesting effect on libvirt. Currently, > libxlDomainFreeMem loops 3 times, then returns 0 (if no errors are > encountered). This means that domain creation starts before dom0 finishes > ballooning (unlike xl's previous behavior, which would fail). > > With this change, domain creation through virsh will wait (in > libxl_wait_for_memory_target) until dom0 finishes ballooning. This should > result in an increase in the speed of the domain starting, as there will not > be memory contention between the two processes. > > The libvirt side calls libxl_wait_for_memory_target with a 1 second timeout - > which doesn't leave a huge amount of room for slow memory allocation. This > timeout, as well as the logic in general, should be changed to match the new > xl behavior (IMO). I expect this to really only matter when dealing with large > domains. For libvirt we also need to consider what happens when a libvirt which is modified along these lines uses an older libxl (I believe back to 4.2 is supported). Ian.