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

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>]

I don't think the proposed logic is particularly tricky, and it won't be slow - the initial test of looking for the first page in a 2.MB extent acts as a good filter.

It will work better than mmarking super pages on the sender.

Ian



----- Original Message -----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <xen-devel-bounces@xxxxxxxxxxxxxxxxxxx>
To: Keir Fraser
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx <xen-devel@xxxxxxxxxxxxxxxxxxx>
Sent: Sat Sep 27 10:19:15 2008
Subject: [Xen-devel] Re: super page with live migration

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

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