From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ulyca-0005jS-Np for qemu-devel@nongnu.org; Mon, 10 Jun 2013 05:42:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UlycX-00071C-Gl for qemu-devel@nongnu.org; Mon, 10 Jun 2013 05:42:40 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:58143 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1UlycX-000716-7W for qemu-devel@nongnu.org; Mon, 10 Jun 2013 05:42:37 -0400 Message-ID: <51B59F81.2020304@kamp.de> Date: Mon, 10 Jun 2013 11:42:25 +0200 From: Peter Lieven MIME-Version: 1.0 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> <1370856815.14883.53.camel@pasglop> In-Reply-To: <1370856815.14883.53.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Benjamin Herrenschmidt Cc: Alexey Kardashevskiy , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Paolo Bonzini , Wenchao Xia , David Gibson On 10.06.2013 11:33, Benjamin Herrenschmidt wrote: > 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. Ok, I see the point. I think the paradigm to say that the destination should "decide" if it needs a page or not is a sound one. Zero pages are quite often depending on the lifetime and the operating system used. But a consecutive range of zero pages is only likely in the bulk stage. I don't know if its reasonable to add a special encoding for that. I will sent a v2 of my previous revert patch addressing Erics concerns shortly. Peter