From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukb9B-0000Z6-9H for qemu-devel@nongnu.org; Thu, 06 Jun 2013 10:26:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ukb99-00046S-UF for qemu-devel@nongnu.org; Thu, 06 Jun 2013 10:26:37 -0400 Received: from ssl.dlhnet.de ([91.198.192.8]:34014 helo=ssl.dlh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukb99-000464-Ob for qemu-devel@nongnu.org; Thu, 06 Jun 2013 10:26:35 -0400 Message-ID: <51B09C19.8090002@dlhnet.de> Date: Thu, 06 Jun 2013 16:26:33 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1370507765-2806-1-git-send-email-pl@kamp.de> <1370507765-2806-2-git-send-email-pl@kamp.de> <1586032558.12669884.1370520984709.JavaMail.root@redhat.com> In-Reply-To: <1586032558.12669884.1370520984709.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] Revert "migration: do not sent zero pages in bulk stage" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aik@ozlabs.ru, pbonzini@redhat.com, Peter Lieven , qemu-devel@nongnu.org, quintela@redhat.com On 06.06.2013 14:16, Eric Blake wrote: > ----- Original Message ----- >> Not sending zero pages breaks migration if a page is zero >> at the source but not at the destination. This can e.g. happen >> if different BIOS versions are used at source and destination. >> It has also been reported that migration on pseries is completely >> broken with this patch. >> >> This reverts commit f1c72795af573b24a7da5eb52375c9aba8a37972. >> >> +++ b/qapi-schema.json >> @@ -499,9 +499,7 @@ >> # >> # @total: total amount of bytes involved in the migration process >> # >> -# @duplicate: number of duplicate (zero) pages (since 1.2) >> -# >> -# @skipped: number of skipped zero pages (since 1.5) >> +# @duplicate: number of duplicate pages (since 1.2) >> # >> # @normal : number of normal pages (since 1.2) >> # >> @@ -514,8 +512,8 @@ >> ## >> { 'type': 'MigrationStats', >> 'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' , >> - 'duplicate': 'int', 'skipped': 'int', 'normal': 'int', >> - 'normal-bytes': 'int', 'dirty-pages-rate' : 'int' } } >> + 'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int', >> + 'dirty-pages-rate' : 'int' } } > This hunk is questionable. Removing something that we have previously sent > over the wire may break clients that are expecting this field to exist. > Rather than reverting the entire patch, you should consider keeping this > field present in QMP, even if you now always populate it with 0. > You are right. I might still account zero pages in the bulk phase to give this field a meaning. These pages are very likely not written on the destination except for the cornercases. What do you think? Peter