From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URNxr-0004Rx-5Q for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URNxo-000053-G1 for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:31:31 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:43239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URNxo-00004u-9K for qemu-devel@nongnu.org; Sun, 14 Apr 2013 10:31:28 -0400 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 14 Apr 2013 08:31:27 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 20D021FF0026 for ; Sun, 14 Apr 2013 08:26: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 r3EEVLxM119384 for ; Sun, 14 Apr 2013 08:31:21 -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 r3EEY9VF031408 for ; Sun, 14 Apr 2013 08:34:09 -0600 Message-ID: <516ABDB8.1090100@linux.vnet.ibm.com> Date: Sun, 14 Apr 2013 10:31:20 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <20130411134820.GA24942@redhat.com> <5166C19A.1040402@linux.vnet.ibm.com> <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> <5168105C.5040605@linux.vnet.ibm.com> <20130414082827.GA1548@redhat.com> In-Reply-To: <20130414082827.GA1548@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 04:28 AM, Michael S. Tsirkin wrote: > On Fri, Apr 12, 2013 at 09:47:08AM -0400, Michael R. Hines wrote: >> Second, as I've explained, I strongly, strongly disagree with unregistering >> memory for all of the aforementioned reasons - workloads do not >> operate in such a manner that they can tolerate memory to be >> pulled out from underneath them at such fine-grained time scales >> in the *middle* of a relocation and I will not commit to writing a solution >> for a problem that doesn't exist. > Exactly same thing happens with swap, doesn't it? > You are saying workloads simply can not tolerate swap. > >> If you can prove (through some kind of anaylsis) that workloads >> would benefit from this kind of fine-grained memory overcommit >> by having cgroups swap out memory to disk underneath them >> without their permission, I would happily reconsider my position. >> >> - Michael > This has nothing to do with cgroups directly, it's just a way to > demonstrate you have a bug. > If your datacenter or your cloud or your product does not want to tolerate page registration, then don't use RDMA! The bottom line is: RDMA is useless without page registration. Without it, the performance of it will be crippled. If you define that as a bug, then so be it. - Michael