From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URIIi-0000CA-HQ for qemu-devel@nongnu.org; Sun, 14 Apr 2013 04:28:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URIIe-0002PQ-J0 for qemu-devel@nongnu.org; Sun, 14 Apr 2013 04:28:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URIIe-0002P8-C5 for qemu-devel@nongnu.org; Sun, 14 Apr 2013 04:28:36 -0400 Date: Sun, 14 Apr 2013 11:28:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20130414082827.GA1548@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5168105C.5040605@linux.vnet.ibm.com> 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 R. Hines" 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 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. -- MST