From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyilJ-0007Dj-PW for qemu-devel@nongnu.org; Tue, 17 Nov 2015 11:05:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyilE-0004D0-PZ for qemu-devel@nongnu.org; Tue, 17 Nov 2015 11:05:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyilE-0004CH-Fk for qemu-devel@nongnu.org; Tue, 17 Nov 2015 11:05:36 -0500 Date: Tue, 17 Nov 2015 16:05:32 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20151117160531.GM2498@work-vm> References: <6a726a501c5dcead1d19f42a43a428baae63ccd7.1429272036.git.bv.trach@gmail.com> <20151117122601.GE2498@work-vm> <564B49E1.4060002@mailbox.tu-dresden.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564B49E1.4060002@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 01:26 PM, Dr. David Alan Gilbert wrote: > > There are a couple of things I don't understand about this: > > 1) How does the source fill it's hashes table? Is it just given the same > > dump file as the destination? > > 2) Why does RAM_SAVE_FLAG_PAGE_HASH exist; if you're sending the full page > > to the destination, why do we also send the hash? > > 1. Migration source is assumed to have the same dump file as the > destination. The design was optimized for the case of ping-pong > migrations over SAN, where checkpoint file is always available. We > also have proof-of-concept code that transfers available hashes from > the migration destination to the source over the network, but it > didn't make it into these patches. OK, it's easy with the SAN then. > 2. We send the hash to avoid hash calculations on the receiving side > to save some CPU time. This flag can be removed, as I don't think the > benefits it provides are big. 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? > > 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? Dave > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > -- > With best regards, > Bohdan Trach -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK