From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UILaM-0002lw-RW for qemu-devel@nongnu.org; Wed, 20 Mar 2013 12:09:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UILaE-0003Su-NZ for qemu-devel@nongnu.org; Wed, 20 Mar 2013 12:09:54 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:48081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UILaE-0003Sj-IR for qemu-devel@nongnu.org; Wed, 20 Mar 2013 12:09:46 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2013 12:09:46 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 050DC6E806D for ; Wed, 20 Mar 2013 12:09:24 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KG9MZF22806586 for ; Wed, 20 Mar 2013 12:09:23 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2KGBvXe002423 for ; Wed, 20 Mar 2013 10:11:57 -0600 Message-ID: <5149DF2C.40402@linux.vnet.ibm.com> Date: Wed, 20 Mar 2013 12:09:16 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1363576743-6146-1-git-send-email-mrhines@linux.vnet.ibm.com> <1363576743-6146-9-git-send-email-mrhines@linux.vnet.ibm.com> <5146D9BF.3030407@redhat.com> <51477A26.8090600@linux.vnet.ibm.com> <51482D78.3010301@redhat.com> <5148643F.2070401@linux.vnet.ibm.com> <51486733.7060207@redhat.com> <51486AD0.80309@linux.vnet.ibm.com> <51486C0D.2040609@redhat.com> <514871C2.5020108@linux.vnet.ibm.com> <5148748C.5050509@redhat.com> <5148AE2F.2030206@linux.vnet.ibm.com> <5148B137.4070300@redhat.com> <5149D3B0.2070500@redhat.com> In-Reply-To: <5149D3B0.2070500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 08/10] introduce QEMUFileRDMA List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, mst@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com On 03/20/2013 11:20 AM, Paolo Bonzini wrote: > Il 19/03/2013 19:40, Paolo Bonzini ha scritto: >>>>>> That however gives me an idea... Instead of the full drain at the end >>>>>> of an iteration, does it make sense to do a "partial" drain at every >>>>>> chunk full, so that you don't have > N bytes pending and the downtime is >>>>>> correspondingly limited? >>>> >>>> Sure, you could do that, but it seems overly complex just to avoid >>>> a single flush() call at the end of each iteration, right? >> Would it really be that complex? Not having an extra QEMUFile op >> perhaps balances that complexity (and the complexity remains hidden in >> rdma.c, which is an advantage). >> >> You could alternatively drain every N megabytes sent, or something like >> that. But a partial drain would help obeying the maximum downtime >> limitations. > On second thought: just keep the drain operation, but make it clear that > it is related to the new save_ram_page QEMUFileOps field. You could > call it flush_ram_pages or something like that. > > Paolo > Acknowledged. This helps a lot, thank you. I'll be sure to clearly conditionalize everything in the next RFC.