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

[Mike Latimer <mlatimer@xxxxxxxx>]

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.

> 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