From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGV5a-0008JQ-CO for qemu-devel@nongnu.org; Thu, 20 Feb 2014 09:59:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGV5P-0000qg-9U for qemu-devel@nongnu.org; Thu, 20 Feb 2014 09:59:02 -0500 Received: from e7.ny.us.ibm.com ([32.97.182.137]:36866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGV5P-0000qV-4D for qemu-devel@nongnu.org; Thu, 20 Feb 2014 09:58:51 -0500 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 20 Feb 2014 09:58:50 -0500 Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 23A4BC90043 for ; Thu, 20 Feb 2014 09:58:45 -0500 (EST) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp23033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1KEwmOk9961824 for ; Thu, 20 Feb 2014 14:58:48 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1KEwlUF007365 for ; Thu, 20 Feb 2014 09:58:47 -0500 Message-ID: <5306181B.9080508@linux.vnet.ibm.com> Date: Thu, 20 Feb 2014 22:58:35 +0800 From: "Michael R. Hines" MIME-Version: 1.0 References: <1392713429-18201-1-git-send-email-mrhines@linux.vnet.ibm.com> <1392713429-18201-2-git-send-email-mrhines@linux.vnet.ibm.com> <20140218124550.GF2662@work-vm> <53040B77.3030008@linux.vnet.ibm.com> <20140219112715.GE2916@work-vm> <530557A4.9040508@linux.vnet.ibm.com> <20140220100927.GA2437@work-vm> <5305E39F.5030601@cn.fujitsu.com> In-Reply-To: <5305E39F.5030601@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 01/12] mc: add documentation for micro-checkpointing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Li Guang , "Dr. David Alan Gilbert" Cc: SADEKJ@il.ibm.com, quintela@redhat.com, hinesmr@cn.ibm.com, qemu-devel@nongnu.org, EREZH@il.ibm.com, owasserm@redhat.com, junqing.wang@cs2c.com.cn, onom@us.ibm.com, abali@us.ibm.com, "Michael R. Hines" , gokul@us.ibm.com, dbulkow@gmail.com, pbonzini@redhat.com, BIRAN@il.ibm.com, isaku.yamahata@gmail.com On 02/20/2014 07:14 PM, Li Guang wrote: > Dr. David Alan Gilbert wrote: >> * Michael R. Hines (mrhines@linux.vnet.ibm.com) wrote: >>> On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote: >>>> I was just wondering if a separate 'max buffer size' knob would allow >>>> you to more reasonably bound memory without setting policy; I don't >>>> think >>>> people like having potentially x2 memory. >>> Note: Checkpoint memory is not monotonic in this patchset (which >>> is unique to this implementation). Only if the guest actually dirties >>> 100% of it's memory between one checkpoint to the next will >>> the host experience 2x memory usage for a short period of time. >> Right, but that doesn't really help - if someone comes along and says >> 'How much memory do I need to be able to run an mc system?' the only >> safe answer is 2x, otherwise we're adding a reason why the previously >> stable guest might OOM. >> > > so we may have to involve some disk operations > to handle memory exhaustion. > > Thanks! Like a cgroups memory limit, for example? - Michael