From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URO6d-0006OH-Id for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:40:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URO6X-00030u-Eg for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:40:35 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:36833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URO6X-00030k-8R for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:40:29 -0400 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 14 Apr 2013 08:40:28 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 2A54119D8041 for ; Sun, 14 Apr 2013 08:40:21 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3EEePE8070070 for ; Sun, 14 Apr 2013 08:40:25 -0600 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 r3EEhDnj018071 for ; Sun, 14 Apr 2013 08:43:13 -0600 Message-ID: <516ABFD8.6070005@linux.vnet.ibm.com> Date: Sun, 14 Apr 2013 10:40:24 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <20130411143718.GC24942@redhat.com> <5166CDAD.8060807@redhat.com> <20130411145632.GA2280@redhat.com> <5166F7AE.8070209@linux.vnet.ibm.com> <20130411191533.GA25515@redhat.com> <51671DFF.80904@linux.vnet.ibm.com> <20130412104802.GA23467@redhat.com> <5167E797.2050103@redhat.com> <20130412112553.GB23467@redhat.com> <51681DAA.3000503@redhat.com> <20130414115911.GA4923@redhat.com> <516AB8A0.3040502@redhat.com> In-Reply-To: <516AB8A0.3040502@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v5: 03/12] comprehensive protocol documentation 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 On 04/14/2013 10:09 AM, Paolo Bonzini wrote: > Il 14/04/2013 13:59, Michael S. Tsirkin ha scritto: >>> I agree assuming guest has lots of zero pages won't work, but I think >>> you are overstating the importance of overcommit. Let's mark the damn >>> thing as experimental, and stop making perfect the enemy of good. >> It looks like we have to decide, before merging, whether migration with >> rdma that breaks overcommit is worth it or not. Since the author made >> it very clear he does not intend to make it work with overcommit, ever. > To me it is very much worth it. > > I would like to understand if unregistration would require a protocol > change, but that's really more a curiosity than anything else. Yes, it would require a protocol change. Either the source or the destination would have to arbitrarily "decide" when is the time to perform the unregistration without adversely causing the page to be RE-registered over and over again during future iterations. I really don't see how QEMU can accurately make such a decision. > Perhaps it would make sense to make chunk registration permanent only > after the bulk phase. Chunks registered in the bulk phase are not > permanent. Unfortunately, that would require the entire memory footprint to be pinned during the bulk round, which was what Michael was originally trying to avoid a couple of weeks ago. Nevertheless, the observation is accurate: We already have a capability to disable chunk registration entirely. If the user doesn't want it, they can just turn it off. - Michael > Paolo >