From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: xl only waits 33 seconds for ballooning to complete Date: Mon, 12 Jan 2015 17:23:05 +0000 Message-ID: <1421083385.28776.26.camel@citrix.com> References: <3571466.tH85X1fGBO@linux-4w67.dnsdhcp.provo.novell.com> <12146633.Z2ive7Pvnf@linux-4w67.dnsdhcp.provo.novell.com> <2335831.uL1mkM9EnT@linux-4w67.dnsdhcp.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2335831.uL1mkM9EnT@linux-4w67.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: George Dunlap , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, 2015-01-12 at 10:04 -0700, Mike Latimer wrote: > On Monday, January 12, 2015 12:36:01 PM George Dunlap wrote: > > I would: > > 1. Reset the retries after a successful increase > > 2. Not allow free_memkb_prev to go down. > > Thanks, George. Good points, which definitely improve the situation. > > > So maybe something like the following? > > > > if (free_memkb <= free_memkb_prev) { > > retries--; > > } else { > > retries = MAX_RETRIES; > > free_memkb_prev = free_memkb; > > } > > Even with a lot of changes in free memory, it seems like the situation should > be better with this change. If free memory does not increase, we will still > encounter the 33 second timeout. On the other hand, as long as memory is being > freed, we continue to wait. > > One case to consider is multiple VMs waiting for memory at the same time. For > example, a 16GB guest attempting to start immediately after a 512GB guest has > triggered the ballooning process. If the 16GB guest starts as soon as 16GB of > memory is free, there is a window of time that free memory would decrease > before the 512GB is freed. With two very large guests, there could be a > situation where the 33 second timeout would be exceeded before free_memkb is > finally greater than free_memkb_prev again. > > I'm not sure whether the above theoretical example would ever be seen in > practice, and even if it could be seen, I think the situation is improved with > the simple solution above. There is a lock at the xl level so the ballooning down should be serialised. > > I'm inclined to say we could add an option to say "wait forever", or > > to increase the period of the checks; but ultimately at some point > > someone (either xl or the human) needs to timeout and say, "This is > > never going to finish". 10s seems like a very conservative default. > > Agreed. Is a better solution to increase the timeout to some larger number and > add an option to "wait forever"? > > Thanks, > Mike > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel