From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBLtB-00045t-EL for qemu-devel@nongnu.org; Wed, 05 Oct 2011 03:27:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBLtA-0007g7-7A for qemu-devel@nongnu.org; Wed, 05 Oct 2011 03:27:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBLtA-0007g1-04 for qemu-devel@nongnu.org; Wed, 05 Oct 2011 03:27:36 -0400 Date: Wed, 5 Oct 2011 09:28:38 -0200 From: "Michael S. Tsirkin" Message-ID: <20111005112837.GA6501@redhat.com> References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <4E88C7DB.9090105@linux.vnet.ibm.com> <20111002210802.GC8072@redhat.com> <4E89B0D4.3090203@us.ibm.com> <20111003133802.GD18920@redhat.com> <4E89BDCE.2010502@codemonkey.ws> <20111003144109.GE19689@redhat.com> <4E89CE20.6050706@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E89CE20.6050706@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , owasserm@redhat.com, Stefan Berger , Michael Roth , qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com On Mon, Oct 03, 2011 at 10:00:48AM -0500, Anthony Liguori wrote: > >Yes, it's easy to quantify. I think the following gives us > >the offset before and after, so the difference is the size > >we seek, right? OK, Orit (Cc'd) did some research - this is a booting while still in grub, size probably does not get much less than that. windows is said to be much more aggressive in allocating memory. start offset: 9600673 end offset: 9614933 So we get 15K out of 9M. By the way, most of the memory here is pretty much all uniform I guess, because compressing it gets us: gzip: 1934169 bzip2 -9: 1462551 So even with aggressive compression, we probably won't be able to get below 1.5M for memory, two orders of magnitude above device state. Sounds convincing? -- MST