From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHXfF-0003CQ-0T for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:51:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHXf7-0004Su-5m for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:51:36 -0400 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:55475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHXf6-0004Rx-Fg for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:51:29 -0400 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Mar 2013 16:17:15 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 93AFA3940053 for ; Mon, 18 Mar 2013 16:21:01 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2IAouKk5570818 for ; Mon, 18 Mar 2013 16:20:56 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2IAp0mB018705 for ; Mon, 18 Mar 2013 10:51:00 GMT Message-ID: <5146F181.70000@linux.vnet.ibm.com> Date: Mon, 18 Mar 2013 18:50:41 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <5142CCB6.7000004@linux.vnet.ibm.com> <20130315145100.GA17187@stefanha-thinkpad.redhat.com> <5146B6F2.3030004@linux.vnet.ibm.com> <20130318090430.GB2476@dhcp-200-207.str.redhat.com> <5146E7B8.9000204@redhat.com> In-Reply-To: <5146E7B8.9000204@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] qmp interface for save vmstate to image List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Juan Quintela , Stefan Hajnoczi , qemu-devel , Dietmar Maurer 于 2013-3-18 18:08, Paolo Bonzini 写道: > Il 18/03/2013 10:04, Kevin Wolf ha scritto: >> Oh, seems I misread this then. I thought this was about internal live >> snapshots, which is a feature that I consider really useful. I'm not so >> sure if saving the VM state as the disk contents of a qcow2 image is >> really helpful. >> >> If zero clusters help a lot, then there's clearly something to improve >> in the migration protocol, because it shouldn't send so many zeros in >> the first place. > > Zero pages are sent as a single 9-byte entry (64 bits for the address > and flags, 8 for the zero). > > I don't expect the migration stream to have a single zero cluster, since > every page is prefixed by the 64 bits for the address and flags. > Furthermore, the RAM data would be horribly unaligned because of this. > 15-20% sectors or so would be read twice, since reading each page (4104 > bytes including the address and flags) would span 10 sectors (5120 bytes). > > Paolo > I think in streaming case, zero page will be handled well. I use qcow2 mainly for fseek() case, which may have some zero holes inside. -- Best Regards Wenchao Xia