From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHyXg-0003pF-Rd for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:33:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHyXa-0004em-7K for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:33:36 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:51548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHyXa-0004ei-1d for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:33:30 -0400 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Mar 2013 09:33:27 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 0B62319D8052 for ; Tue, 19 Mar 2013 09:32:52 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2JFWqh8111146 for ; Tue, 19 Mar 2013 09:32:53 -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 r2JFWqg6020108 for ; Tue, 19 Mar 2013 09:32:52 -0600 Message-ID: <51488521.4010909@linux.vnet.ibm.com> Date: Tue, 19 Mar 2013 11:32:49 -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> In-Reply-To: <20130319151606.GA13649@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 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? A simple solution would be to just have QEMU consult with /dev/pagemap, no? - Michael