From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyiKk-0002Ow-8Z for qemu-devel@nongnu.org; Tue, 17 Nov 2015 10:38:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyiKg-0004Cb-8O for qemu-devel@nongnu.org; Tue, 17 Nov 2015 10:38:14 -0500 Received: from mailout2.zih.tu-dresden.de ([141.30.67.73]:45927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyiKg-0004CU-2c for qemu-devel@nongnu.org; Tue, 17 Nov 2015 10:38:10 -0500 References: <6a726a501c5dcead1d19f42a43a428baae63ccd7.1429272036.git.bv.trach@gmail.com> <20151117122601.GE2498@work-vm> From: Bohdan Trach Message-ID: <564B49E1.4060002@mailbox.tu-dresden.de> Date: Tue, 17 Nov 2015 16:38:09 +0100 MIME-Version: 1.0 In-Reply-To: <20151117122601.GE2498@work-vm> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: "Dr. David Alan Gilbert" Cc: amit.shah@redhat.com, thomas.knauth@googlemail.com, qemu-devel@nongnu.org, quintela@redhat.com 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. 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. > 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. > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- With best regards, Bohdan Trach