From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHy9V-0001hd-H2 for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:08:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHy9P-00036z-BC for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:08:37 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:58854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHy9P-00036s-77 for qemu-devel@nongnu.org; Tue, 19 Mar 2013 11:08:31 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Mar 2013 11:08:30 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id D00B8C90029 for ; Tue, 19 Mar 2013 11:08:25 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2JF8Pix232596 for ; Tue, 19 Mar 2013 11:08:25 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2JF8OMa010699 for ; Tue, 19 Mar 2013 11:08:24 -0400 Message-ID: <51487F68.2060305@linux.vnet.ibm.com> Date: Tue, 19 Mar 2013 11:08:24 -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> In-Reply-To: <20130319081939.GC11259@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 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 On 03/19/2013 04:19 AM, Michael S. Tsirkin wrote: > On Mon, Mar 18, 2013 at 07:23:53PM -0400, Michael R. Hines wrote: >> On 03/18/2013 05:26 PM, Michael S. Tsirkin wrote: >>> Probably but I haven't mentioned ballooning at all. >>> >>> memory overcommit != ballooning >> Sure, then setting ballooning aside for the moment, >> then let's just consider regular (unused) virtual memory. >> >> In this case, what's wrong with the destination mapping >> and pinning all the memory if it is not being ballooned? >> >> If the guest touches all the memory during normal operation >> before migration begins (which would be the common case), >> then overcommit is irrelevant, no? > We have ways (e.g. cgroups) to limit what a VM can do. If it tries to > use more RAM than we let it, it will swap, still making progress, just > slower. OTOH it looks like pinning more memory than allowed by the > cgroups limit will just get stuck forever (probably a bug, > should fail instead? but does not help your protocol > which needs it all pinned at all times). > > There are also per-task resource limits. If you exceed this > registration will fail, so not good either. > > I just don't see why do registration by chunks > on source but not on destination. >