From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39088) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJyBJ-0003ES-Dn for qemu-devel@nongnu.org; Tue, 28 Jul 2015 02:16:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJyBG-0001Yw-8e for qemu-devel@nongnu.org; Tue, 28 Jul 2015 02:16:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJyBG-0001Yb-4P for qemu-devel@nongnu.org; Tue, 28 Jul 2015 02:16:02 -0400 Date: Tue, 28 Jul 2015 11:45:47 +0530 From: Amit Shah Message-ID: <20150728061547.GL12267@grmbl.mre> References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-43-git-send-email-dgilbert@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1434450415-11339-43-git-send-email-dgilbert@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 42/42] Inhibit ballooning during postcopy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert (git)" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, liang.z.li@intel.com, qemu-devel@nongnu.org, luis@cs.umu.se, pbonzini@redhat.com, david@gibson.dropbear.id.au On (Tue) 16 Jun 2015 [11:26:55], Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > 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