From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URNu4-00037R-SU for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:27:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URNu1-0006H7-ME for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:27:36 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:49070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URNu1-0006GF-Fy for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:27:33 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 14 Apr 2013 08:27:29 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id F1A9E1FF003C for ; Sun, 14 Apr 2013 08:22:25 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3EERQGY333516 for ; Sun, 14 Apr 2013 08:27:26 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3EERQp3014909 for ; Sun, 14 Apr 2013 08:27:26 -0600 Message-ID: <516ABCCC.207@linux.vnet.ibm.com> Date: Sun, 14 Apr 2013 10:27: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> In-Reply-To: <20130414115911.GA4923@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: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, Paolo Bonzini On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote: > On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote: >> Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto: >>> On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote: >>>> Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto: >>>>> 1. You have two protocols already and this does not make sense in >>>>> version 1 of the patch. >>>> It makes sense if we consider it experimental (add x- in front of >>>> transport and capability) and would like people to play with it. >>>> >>>> Paolo >>> But it's not testable yet. I see problems just reading the >>> documentation. Author thinks "ulimit -l 10000000000" on both source and >>> destination is just fine. This can easily crash host or cause OOM >>> killer to kill QEMU. So why is there any need for extra testers? Fix >>> the major bugs first. >>> >>> There's a similar issue with device assignment - we can't fix it there, >>> and despite being available for years, this was one of two reasons that >>> has kept this feature out of hands of lots of users (and assuming guest >>> has lots of zero pages won't work: balloon is not widely used either >>> since it depends on a well-behaved guest to work correctly). >> 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. >> >> Paolo > 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. > That depends entirely as what you define as overcommit. The pages do get unregistered at the end of the migration =) - Michael