From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTzi6-0002U4-6x for qemu-devel@nongnu.org; Sun, 21 Apr 2013 15:14:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTzi3-000273-Jz for qemu-devel@nongnu.org; Sun, 21 Apr 2013 15:14:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTzi3-00026x-2R for qemu-devel@nongnu.org; Sun, 21 Apr 2013 15:13:59 -0400 Date: Sun, 21 Apr 2013 22:13:44 +0300 From: "Michael S. Tsirkin" Message-ID: <20130421191344.GB17565@redhat.com> References: <1366240040-10730-1-git-send-email-mrhines@linux.vnet.ibm.com> <1366240040-10730-8-git-send-email-mrhines@linux.vnet.ibm.com> <51706E9C.9@redhat.com> <20130420170240.GA16115@redhat.com> <5173E759.5080906@redhat.com> <20130421141746.GB13512@redhat.com> <51741F95.20501@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51741F95.20501@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PULL v4 07/11] rdma: introduce capability for chunk registration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" Cc: aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, Paolo Bonzini On Sun, Apr 21, 2013 at 01:19:17PM -0400, Michael R. Hines wrote: > On 04/21/2013 10:17 AM, Michael S. Tsirkin wrote: > >On Sun, Apr 21, 2013 at 03:19:21PM +0200, Paolo Bonzini wrote: > >>Il 20/04/2013 19:02, Michael S. Tsirkin ha scritto: > >>>>>I guess the opposite sense could be named 'x-rdma-pin-all'; default > >>>>>false means to do chunk registration and release, > >>>chunk release only happens after migration is complete unfortunately. > >>>This means that eventually all initialized memory is pinned, regardless > >>>of the setting (this is fixable but there's no plan to fix this, at this > >>>point). So pin-all might be misleading to some. > >>> > >>>I agree 'chunk' is unnecessarily low level though. > >>>The only difference ATM is pinning of uninitialized memory so I think a > >>>better name would be 'x-rdma-pin-uninitialized' or some such. > >>> > >>x-rdma-pin-all is a better choice. x-rdma-pin-uninitialized is also too > >>low level. > >> > >>Since this series is likely to miss 1.5 at this point, we could > >>implement the unregistration part of the protocol in the destination. > >>This way, any heuristic we add to the source will not break backwards > >>compatibility. > >> > >>Paolo > >To test, you'll have to implement it in the source too. > >That's probably a good idea anyway, though doing this > >efficiently might need more thought, and some of > >the tricks I described earlier (pipelining, > >registration cache) might be needed. > >Though I'm curious what the performance impact would be > >even without these tricks. > > > > We already had a agreement to merge with ulimit -l + ibv_reg_mr() + > ERROR + abort migration. Not sure who is 'we' here, but for the record, I did not agree to merge these patches, and I'm the wrong person to ask to merge them. Juan is probably the right person to ask about merging them. > We (IBM Research) will not commit to implementing this unless someone > provides hard data showing it not to adversely effect migration performance. > > - Michael -- MST