From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlx6Z-00076L-LR for qemu-devel@nongnu.org; Thu, 28 Nov 2013 03:37:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vlx6Q-0007fC-9d for qemu-devel@nongnu.org; Thu, 28 Nov 2013 03:37:47 -0500 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:59906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlwpP-00023N-5G for qemu-devel@nongnu.org; Thu, 28 Nov 2013 03:20:03 -0500 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 28 Nov 2013 13:49:54 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 47B9CE0056 for ; Thu, 28 Nov 2013 13:51:57 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAS8JiDe62128214 for ; Thu, 28 Nov 2013 13:49:44 +0530 Received: from d28av01.in.ibm.com (localhost [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAS8JncU003834 for ; Thu, 28 Nov 2013 13:49:50 +0530 Message-ID: <5296FCA3.7020003@linux.vnet.ibm.com> Date: Thu, 28 Nov 2013 16:19:47 +0800 From: Lei Li MIME-Version: 1.0 References: <1385025100-3191-1-git-send-email-lilei@linux.vnet.ibm.com> <1385025100-3191-17-git-send-email-lilei@linux.vnet.ibm.com> <529486B5.90500@redhat.com> <52948E18.6070503@linux.vnet.ibm.com> <52949A19.1010307@redhat.com> <5294A7EC.4060501@linux.vnet.ibm.com> <5294AC22.2020105@redhat.com> In-Reply-To: <5294AC22.2020105@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 16/17] migration: adjust migration_thread() process for page flipping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aarcange@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, mrhines@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com, aliguori@amazon.com, lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com On 11/26/2013 10:11 PM, Paolo Bonzini wrote: > Il 26/11/2013 14:53, Lei Li ha scritto: >> 1) ram_save_setup stage, it will send all the bytes in this stages >> to destination, and send_pipefd by ram_control_before_iterate >> at the end of it. > ram_save_setup runs doesn't send anything from guest RAM. It sends the > lengths of the various blocks. As you said, at the end of > ram_save_setup you send the pipefd. > > ram_save_iterate runs before ram_save_complete. ram_save_iterate and > ram_save_complete write data with exactly the same format. Both of them > can use ram_save_page > > It should not matter if some pages are sent as part of ram_save_iterate > and others as part of ram_save_complete. > > One possibility is that you are hitting a bug due to the way you ignore > the "0x01" byte that send_pipefd places on the socket. > >>> Oops. I might have said this before thinking about postcopy and/or >>> before seeing the benchmark results from Juan's patches. If this part >>> of the patch is just an optimization, I'd rather leave it out for now. >> I am afraid that page flipping can not proceed correctly without this.. > I really would like to understand why, because it really shouldn't (this > shouldn't be a place where you need a hook). Hi Paolo, Sorry for the late reply. Yes, you are right!! I just have a try with this adjustment removed, it works well... I remembered that it can not proceed correctly when debugging in previous version without this as in theory it should like your explanation above. I guess the only answer is that there was a bug regarding the one byte fd control message just like the possibility you listed! > > Paolo > > -- Lei