From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdjGY-0000YZ-LS for qemu-devel@nongnu.org; Thu, 11 Sep 2008 06:19:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdjGX-0000WU-6o for qemu-devel@nongnu.org; Thu, 11 Sep 2008 06:19:09 -0400 Received: from [199.232.76.173] (port=52953 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdjGW-0000WI-SA for qemu-devel@nongnu.org; Thu, 11 Sep 2008 06:19:08 -0400 Received: from il.qumranet.com ([212.179.150.194]:54645) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdjGW-0007Th-9C for qemu-devel@nongnu.org; Thu, 11 Sep 2008 06:19:08 -0400 Message-ID: <48C8F00A.90900@qumranet.com> Date: Thu, 11 Sep 2008 13:16:42 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/10] Allow the monitor to be suspended during non-blocking op 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> In-Reply-To: <20080910155831.GA30342@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Chris Wright , Uri Lublin , Anthony Liguori , kvm@vger.kernel.org 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.