From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH 2/10] Allow the monitor to be suspended during non-blocking op Date: Thu, 11 Sep 2008 13:16:42 +0300 Message-ID: <48C8F00A.90900@qumranet.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Chris Wright , Uri Lublin , Anthony Liguori , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from il.qumranet.com ([212.179.150.194]:54650 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbYIKKTI (ORCPT ); Thu, 11 Sep 2008 06:19:08 -0400 In-Reply-To: <20080910155831.GA30342@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: 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. > 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.