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

[Amit Shah]

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.

                Amit