[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 45/45] Inhibit ballooning during postcopy
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH v5 45/45] Inhibit ballooning during postcopy |
Date: |
Tue, 24 Mar 2015 12:25:13 +1100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Mon, Mar 23, 2015 at 12:21:50PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (address@hidden) wrote:
> > On Wed, Feb 25, 2015 at 04:52:08PM +0000, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > >
> > > 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
pgpVZlegbx2A2.pgp
Description: PGP signature