WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: super page with live migration

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: super page with live migration
From: "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Date: Sat, 27 Sep 2008 17:19:15 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 27 Sep 2008 02:19:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5026407.277BC%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C5026407.277BC%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080707)
Keir Fraser wrote:
On 26/9/08 08:45, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:

As you know, we try to allocate super pages in xc_hvm_build for better
performance in EPT case. But the same logic is missing in xc_domain_restore.

When try to add the logic, I found it is blocked by the lazy populate
algorithm in restore -- only populating the pages received from source side rather than
doing it at one time.

So the result is the EPT guest has performance drop after live migration:(

Do you have any plan to change the lazy populate algorithm? The purpose of it,
I believe, is to make restore process work without guest memory layout knowledge.

Yes: If pseudo-phys page is not yet populated in target domain, AND it is
first page of a 2MB extent, AND no other pages in that extent are yet
populated, AND the next pages in the save-image stream populate that extent
in order, THEN allocate a superpage. This is made trickier by the fact that
the next 511 pages (to make the 2MB extent) might be split across a batch
boundary. So we'll have to optimistically allocate a superpage in that case,
and then shatter it if it turns out that the contiguous stream of
pseudo-phys addresses is broken in the next batch.

It's really tricky logic, and may make the migration process longer:(

Maybe the flag the start-of-a-superpage as Tim said can make it easier.



Thanks,


 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel