From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyjId-0004kq-Lj for qemu-devel@nongnu.org; Tue, 17 Nov 2015 11:40:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyjIa-0004xq-Gt for qemu-devel@nongnu.org; Tue, 17 Nov 2015 11:40:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyjIa-0004xd-C0 for qemu-devel@nongnu.org; Tue, 17 Nov 2015 11:40:04 -0500 Date: Tue, 17 Nov 2015 16:39:59 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20151117163959.GN2498@work-vm> References: <6a726a501c5dcead1d19f42a43a428baae63ccd7.1429272036.git.bv.trach@gmail.com> <20151117122601.GE2498@work-vm> <564B49E1.4060002@mailbox.tu-dresden.de> <20151117160531.GM2498@work-vm> <564B56FA.9050807@mailbox.tu-dresden.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564B56FA.9050807@mailbox.tu-dresden.de> Subject: Re: [Qemu-devel] [PATCH RFC 3/3] migration: use checkpoint during migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bohdan Trach Cc: amit.shah@redhat.com, thomas.knauth@googlemail.com, qemu-devel@nongnu.org, quintela@redhat.com * Bohdan Trach (bohdan.trach@mailbox.tu-dresden.de) wrote: > > On 11/17/2015 05:05 PM, Dr. David Alan Gilbert wrote: > > Why is the hash needed on the destination; if it's a page which the source > > has decided isn't in a matching page, what does the destination use the > > hash for? > > > > After the migration has finished, the hashes are still stored in RAM > for the next migration, when the current destination becomes the new > migration source. This way there is no need to recompute the checksums > on the next migration -- they are already in RAM. > > >>> I think there's a problem here that given the source is still running it's CPU and changing > >>> memory; it can be writing to the page at the same time, so the page you send might not > >>> match the hash you send; we're guaranteed to resend the page again if it was written > >>> to, but that still doesn't make these two things match; although as I say above > >>> I'm not sure why SAVE_FLAG_PAGE_HASH exists. > >> > >> This is true. In this case, we will just delete the SAVE_FLAG_PAGE_HASH flag. > > > > But how do you know to delete the SAVE_FLAG_PAGE_HASH flag? > > > > Sorry for not stating this clear enough. We will remove this flag from > the code, and send pages with SAVE_FLAG_PAGE instead. In this case the > destination will compute the hash. OK, that's fine. Dave > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > > > -- > With best regards, > Bohdan Trach -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK