From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KdkqA-0007jc-Iq
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 08:00:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kdkq9-0007il-Kp
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 08:00:01 -0400
Received: from [199.232.76.173] (port=34879 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kdkq9-0007iU-9s
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 08:00:01 -0400
Received: from mail2.shareable.org ([80.68.89.115]:46128)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1Kdkq8-0008TL-WE
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 08:00:01 -0400
Date: Thu, 11 Sep 2008 12:59:56 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 2/10] Allow the monitor to be
	suspended	during non-blocking op
Message-ID: <20080911115956.GB16427@shareable.org>
References: <1220989802-13706-1-git-send-email-aliguori@us.ibm.com>
	<1220989802-13706-3-git-send-email-aliguori@us.ibm.com>
	<48C76EB1.6040906@qumranet.com> <20080910100520.GE2662@redhat.com>
	<48C7AB7C.30407@qumranet.com>
	<20080910155831.GA30342@shareable.org>
	<48C8F00A.90900@qumranet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48C8F00A.90900@qumranet.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Uri Lublin <uri.lublin@qumranet.com>, Anthony Liguori <aliguori@us.ibm.com>, kvm@vger.kernel.org

Avi Kivity wrote:
> Jamie Lokier wrote:
> > Avi Kivity wrote:
> >   
> >> (logically we would copy all of the data of all block devices, but 
> >> that's not very practical, so we assume shared storage).
> >>     
> >
> > Speaking of that, if the guest RAM were a memory-mapped file, couldn't
> > that use shared storage too?
> 
> You would need a clustered filesystem that supports coherent mmap()s.

Yes, something like GFS.

> > You'd have to be careful: it would need a distributed filesystem with
> > coherent mappings (i.e. not NFS), but they do exist.
> >
> > I'm guessing that the bulk of time spent in migration/checkpointing is
> > saving the RAM image.  Using a memory-mapped file on shared storage
> > for RAM might make that faster.  (Or slower!).
> >   
> The memory needs to be transferred anyway, so total time would not
> change.  You could start running on the target sooner, though.

Actually the memory doesn't need to be tranferred.  Only actively used
pages need to be.  If you have an 8GB guest, 7.75GB of which is the
guest's filesystem cache from something you did earlier and is no
longer used, you just need to transfer 250MB and it can continue
running on the target.

-- Jamie