Re: [Qemu-devel] [PATCH v7 42/42] Inhibit ballooning during postcopy

[Amit Shah]

On (Tue) 28 Jul 2015 [10:08:15], Dr. David Alan Gilbert wrote:
> * Amit Shah (address@hidden) wrote:
> > On (Tue) 16 Jun 2015 [11:26:55], Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > > 
> > > Postcopy detects accesses to pages that haven't been transferred yet
> > > using userfaultfd, and it causes exceptions on pages that are 'not
> > > present'.
> > > Ballooning also causes pages to be marked as 'not present' when the
> > > guest inflates the balloon.
> > > Potentially a balloon could be inflated to discard pages that are
> > > currently inflight during postcopy and that may be arriving at about
> > > the same time.
> > > 
> > > To avoid this confusion, disable ballooning during postcopy.
> > > 
> > > When disabled we drop balloon requests from the guest.  Since ballooning
> > > is generally initiated by the host, the management system should avoid
> > > initiating any balloon instructions to the guest during migration,
> > > although it's not possible to know how long it would take a guest to
> > > process a request made prior to the start of migration.
> > > 
> > > Queueing the requests until after migration would be nice, but is
> > > non-trivial, since the set of inflate/deflate requests have to
> > > be compared with the state of the page to know what the final
> > > outcome is allowed to be.
> > 
> > I didn't track the previous discussion, but there were plans to have
> > guest-initiated balloon requests for cases where the guest wants to
> > co-operate with hosts and return any free mem available We don't
> > currently have guests that do this, but we also don't want to have a
> > dependency between the host and guest -- they should be independent.
> > 
> > This approach here seems the simplest possible, short of maintaining
> > another bitmap for the duration of postcopy which indicates
> > guest-freed memory pages which postcopy should not populate, after
> > receiving them at the dest (this sounds better to me than queuing up
> > guest requests).
> > 
> > The downside here is that the guest offered some memory back, and we
> > don't use it.  The guest also doesn't use it -- so it's a double loss,
> > of sorts.
> > 
> > Thoughts?  I don't have a problem with this current approach, but if
> > we could get something better, that'll be good too.
> 
> It needs something like that bitmap, but it would take quite a bit
> of care to manage the interaction between:
>     a) The guest emitting balloon notifications
>     b) Pages being received from the source
>     c) Destination use of that page
> 
>   we also have to think what to do with a page that's been ballooned
> after reception of the source page; the madvise(dontneed) that's used
> normally would cause userfault to fire again, and we can't allow that.
> (We could make it the same as receiving a zero page).   But then we would
> also have to cope with  the source sending us a page after the destination
> has ballooned it and make sure to discard that (I suspect there are further
> ordering examples that have to also be considered).

Yeah.  I'm fine with the current approach, with the downsides
mentioned.  Maybe in the commit message, make it explicit that the
guest may think it's given up ownership, but the host won't honour
this till postcopy isn't finished.

Anyway:

Reviewed-by: Amit Shah <address@hidden>


                Amit