From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI0Wd-0007Nw-Hm for qemu-devel@nongnu.org; Tue, 19 Mar 2013 13:40:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UI0WZ-0002iJ-Bd for qemu-devel@nongnu.org; Tue, 19 Mar 2013 13:40:39 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:53780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI0WZ-0002ht-5o for qemu-devel@nongnu.org; Tue, 19 Mar 2013 13:40:35 -0400 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Mar 2013 11:40:33 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 5150A3E4006F for ; Tue, 19 Mar 2013 11:40:17 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2JHeLao117750 for ; Tue, 19 Mar 2013 11:40:22 -0600 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 r2JHglF8012496 for ; Tue, 19 Mar 2013 11:42:47 -0600 Message-ID: <5148A2F6.1070206@linux.vnet.ibm.com> Date: Tue, 19 Mar 2013 13:40:06 -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> <51489BC3.3030504@linux.vnet.ibm.com> <51489D05.2000400@redhat.com> In-Reply-To: <51489D05.2000400@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: Paolo Bonzini Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com OK, so I did a quick test and the cgroup does appear to be working correctly for zero pages. Nevertheless, this still doesn't solve the chunk registration problem for RDMA. Even with a cgroup on the sender *or* receiver side, there is no API that I know that would correctly indicate to the migration process which pages are safe to register or not with the hardware. Without such an API, even a "smarter" chunked memory registration scheme would not work with cgroups because we would be attempting to pin zero pages (for no reason) that cgroups has already kicked out, which would defeat the purpose of using cgroups. So, if I submit a separate patch to fix this, would you guys review it? (Using /dev/pagemap). Unless there is a better idea? Does KVM expose the necessary mappings? - Michael On 03/19/2013 01:14 PM, Paolo Bonzini wrote: > Il 19/03/2013 18:09, Michael R. Hines ha scritto: >> 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..... > Would it swap? Doesn't the kernel back all zero pages with a single > copy-on-write page? If that still accounts towards cgroup limits, it > would be a bug. > > Old kernels do not have a shared zero hugepage, and that includes some > distro kernels. Perhaps that's the problem. > > Paolo >