Re: [Qemu-devel] [PATCH v5 45/45] Inhibit ballooning during postcopy

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

On Mon, Mar 23, 2015 at 12:21:50PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > On Wed, Feb 25, 2015 at 04:52:08PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > 
> > > The userfault mechanism used for postcopy generates faults
> > > for us on pages that are 'not present', inflating a balloon in
> > > the guest causes host pages to be marked as 'not present'; doing
> > > this during a postcopy, as potentially the same pages were being
> > > received from the source, would confuse the state of the received
> > > page -> disable ballooning during postcopy.
> > 
> > That is a ludicrously long sentence, which I have great difficulty parsing.
> 
> OK, how about:
> 
> -----
> 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.

Better, thanks.

> -----
> 
> > > 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.
> > 
> > Yeah :/.  It would be nice if it could queue the guest actions,
> > instead of dropping them.
> 
> Yes, I did look at that briefly; it's not trivial; for
> example consider the situation where the guest discards some pages
> by inflating, and then later deflates, it expects to lose that data
> but then starts accessing that physical page again.  
> If you replay that sequence at the end then you've lost newly accessed pages.
> So you have to filter out inflates that have been deflated later,
> and have to order those correctly with the sense of changes made to those
> pages after the deflation occurs.

Ah, yes, I see.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]