From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQK1U-0005Al-5p for qemu-devel@nongnu.org; Thu, 11 Apr 2013 12:06:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQK1M-0002EP-2j for qemu-devel@nongnu.org; Thu, 11 Apr 2013 12:06:52 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:38483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQK1L-0002EB-VZ for qemu-devel@nongnu.org; Thu, 11 Apr 2013 12:06:44 -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 ; Thu, 11 Apr 2013 12:06:41 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id D04D938C8736 for ; Thu, 11 Apr 2013 12:03:00 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3BG30EC275160 for ; Thu, 11 Apr 2013 12:03:00 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3BG2uJi004267 for ; Thu, 11 Apr 2013 13:02:56 -0300 Message-ID: <5166DEAB.5070309@linux.vnet.ibm.com> Date: Thu, 11 Apr 2013 12:02:51 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1365632901-15470-1-git-send-email-mrhines@linux.vnet.ibm.com> <1365632901-15470-11-git-send-email-mrhines@linux.vnet.ibm.com> <20130411073843.GB19601@redhat.com> <51667FEE.903@redhat.com> <5166B9A9.9070904@linux.vnet.ibm.com> <5166C59A.4010904@redhat.com> <5166CF56.2060105@linux.vnet.ibm.com> <5166D1DA.3050804@redhat.com> <5166D826.207@linux.vnet.ibm.com> <5166DAA0.1010507@redhat.com> In-Reply-To: <5166DAA0.1010507@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v1: 10/13] introduce new command migrate_check_for_zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com Alright, so here's a slightly different management decision which tries to accomplish all the requests, tell me if you like it: 1. QEMU starts up 2. *if and only if* chunk registration is disabled and *if and only* RDMA is enabled then, is_dup_page() is skipped Otherwise, everything is same as before, no change in code path and no zero page capability needs to be exposed to management In this case there would be *no* capability for zero pages, but we would still be able to detect the motivation of the user indirectly through the chunk registration capability by implying that since the capability was disabled then the user is trying to optimize metrics for total migration time. On the other hand, if the chunk registration capability is enabled, then there is no change in the code path we because zero page checking is mandatory to take of chunk registration in the first place. How does that sound? No zero page capability, but allow for disabling only if chunk registration is disabled? - Michael On 04/11/2013 11:45 AM, Paolo Bonzini wrote: > Il 11/04/2013 17:35, Michael R. Hines ha scritto: >> Nevertheless, the initial "burst" of the bulk phase round is still >> important to optimize, and I would like to know if the maintainer >> would accept this API for disabling the scan or not > I'm not a maintainer, but every opinion counts... and my opinion is "not > yet". Maybe for 1.6, and only after someone else tried it out. That's > why it's important to merge the code early. > >> We think it's important because the total migration time can be much >> smaller with high-throughput RDMA links by optimizing the bulk-phase >> round and that lower total migration time is very valuable to many of >> our workloads, in addition to the low-downtime benefits you get with >> RDMA. >> >> I have expensive numbers only for the bulk phase round. Other than that, >> I would be breaking confidentiality outside of the paper we have already >> published. > Fair enough. > > Paolo >