From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHyaO-0005ed-Ka for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:36:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHyaL-00068Z-Ub for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:36:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHyaL-00068T-Mc for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:36:21 -0400 Date: Tue, 19 Mar 2013 17:36:58 +0200 From: "Michael S. Tsirkin" Message-ID: <20130319153658.GA14317@redhat.com> References: <1363576743-6146-1-git-send-email-mrhines@linux.vnet.ibm.com> <1363576743-6146-4-git-send-email-mrhines@linux.vnet.ibm.com> <20130318104013.GE5267@redhat.com> <5147780C.1080800@linux.vnet.ibm.com> <20130318212646.GB20406@redhat.com> <5147A209.80202@linux.vnet.ibm.com> <20130319081939.GC11259@redhat.com> <51487F68.2060305@linux.vnet.ibm.com> <20130319151606.GA13649@redhat.com> <51488521.4010909@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51488521.4010909@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport 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, pbonzini@redhat.com On Tue, Mar 19, 2013 at 11:32:49AM -0400, Michael R. Hines wrote: > On 03/19/2013 11:16 AM, Michael S. Tsirkin wrote: > >On Tue, Mar 19, 2013 at 11:08:24AM -0400, Michael R. Hines wrote: > >>This is actual a much bigger problem that I thought, not just for RDMA: > >> > >>Currently the *sender* side is does not support overcommit > >>during a regular TCP migration.......I assume because the > >>migration_bitmap does not know which memory is mapped or > >>unmapped by the host kernel. > >> > >>Is this a known issue? > >> > >>- Michael > >I don't really understand what you are saying here. > >Do you see some bug with migration where we might use > >more memory than allowed by cgroups? > > > > Yes: cgroups does not coordinate with the list of pages > that have "not yet been mapped" or touched by the > virtual machine, right? > > I may be missing something here from what I read in > the code, but even if I set a cgroups limit on memory, > QEMU will still attempt to access that memory if the > migration_bitmap tells it to, as far as I can tell. > > Is this an accurate observation? Yes but this simply means QEMU will hit swap. > A simple solution would be to just have QEMU consult with /dev/pagemap, no? > > - Michael