Re: [Xen-devel] xl only waits 33 seconds for ballooning to complete

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel