From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI039-00074E-BM for qemu-devel@nongnu.org; Tue, 19 Mar 2013 13:10:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UI033-0001Yp-0G for qemu-devel@nongnu.org; Tue, 19 Mar 2013 13:10:11 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:46166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI032-0001YB-PK for qemu-devel@nongnu.org; Tue, 19 Mar 2013 13:10:04 -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 ; Tue, 19 Mar 2013 11:10:04 -0600 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 05ED0C90067 for ; Tue, 19 Mar 2013 13:09:57 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2JH9u5n308940 for ; Tue, 19 Mar 2013 13:09:56 -0400 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 r2JHC3Op016979 for ; Tue, 19 Mar 2013 11:12:03 -0600 Message-ID: <51489BC3.3030504@linux.vnet.ibm.com> Date: Tue, 19 Mar 2013 13:09:23 -0400 From: "Michael R. Hines" MIME-Version: 1.0 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> <20130319153658.GA14317@redhat.com> In-Reply-To: <20130319153658.GA14317@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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, pbonzini@redhat.com Allowing QEMU to swap due to a cgroup limit during migration is a viable overcommit option? I'm trying to keep an open mind, but that would kill the migration time..... - Michael On 03/19/2013 11:36 AM, Michael S. Tsirkin wrote: > 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