From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlyUB-0002vS-Fm for qemu-devel@nongnu.org; Mon, 10 Jun 2013 05:34:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UlyUA-0004LL-3r for qemu-devel@nongnu.org; Mon, 10 Jun 2013 05:33:59 -0400 Message-ID: <1370856815.14883.53.camel@pasglop> From: Benjamin Herrenschmidt Date: Mon, 10 Jun 2013 19:33:35 +1000 In-Reply-To: <51B5980B.6030200@ozlabs.ru> References: <51A7036A.3050407@ozlabs.ru> <51A7049F.6040207@redhat.com> <51A70B3D.90609@ozlabs.ru> <51A71705.6060009@kamp.de> <51A74D79.7040204@redhat.com> <2765FDFA-8050-4AA3-8621-7E9EA2C89F9C@kamp.de> <51A764FC.7080705@redhat.com> <51ADF122.70307@kamp.de> <51ADF637.7060804@redhat.com> <51ADFBCE.3080200@kamp.de> <51ADFC7A.7030009@redhat.com> <51AE035A.5070301@kamp.de> <51B2EB0A.7000704@linux.vnet.ibm.com> <51B2EBA2.5060401@ozlabs.ru> <51B3E58C.50301@linux.vnet.ibm.com> <51B3E9A8.5010705@ozlabs.ru> <51B3EFFA.4040608@linux.vnet.ibm.com> <51B3F1FD.1090401@ozlabs.ru> <51B57489.20802@ozlabs.ru> <51B57727.9080903@kamp.de> <51B5785B.6040704@ozlabs.ru> <51B591D1.5040705@kamp.de> <51B5980B.6030200@ozlabs.ru> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] broken incoming migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Peter Lieven , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Paolo Bonzini , Wenchao Xia , David Gibson On Mon, 2013-06-10 at 19:10 +1000, Alexey Kardashevskiy wrote: > > I would prefer not to completely drop the patch since it saves bandwidth and > > resources. > > I would like migration to do what it should do - send pages no matter what, > this is exactly what migration is for. If there any many, many empty pages > (which I doubt to be a very often real life case), they could all merged in > big consecutive chunks and sent at the end of migration. I tend to agree. The problem of sending empty pages is purely a problem of compression. If the current mechanism is deemed "not efficient enough" for in the case of having lots of zero-pages, then by all means invent a better packet format for more tightly representing them on the wire, but don't break things by not sending them at all. Cheers, Ben.