This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Dynamic Loading of Domain Memory Image

To: Joe Laws <jlaws@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Dynamic Loading of Domain Memory Image
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 17:32:04 +0100
Delivery-date: Tue, 27 Mar 2007 09:31:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <460941B5.1080600@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdwjXPesnCIxNyAEdu1BgAX8io7RQ==
Thread-topic: [Xen-devel] Dynamic Loading of Domain Memory Image
User-agent: Microsoft-Entourage/
On 27/3/07 17:09, "Joe Laws" <jlaws@xxxxxxxxxxxxxx> wrote:

> Although this project is geared toward decreasing the resume time when
> the memory image is sent over the internet, it should also decrease
> resume time when loading from the local disk.  There is also the
> possibility that it will decrease migration resume time since all dirty
> pages can be marked as "not present/trap to hypervisor" at which point
> they can be dynamically loaded in a similar fashion.

The problem with pull-based resume is that unless you have pushed the
working set ahead of time (or are in the process of pushing those pages
first) then performance will suck pretty bad as you'll spend all your time
demand-fetching pages with a wide-area RTT latency per page. Is this better
than running the machine in its original location, pushing the pages, and
connecting to the machine remotely until the memory image is fully built up
at the destination? Perhaps you need to build it to find out...

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>