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

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

To: 'Ian Pratt' <Ian.Pratt@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: super page with live migration
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 6 Oct 2008 08:45:28 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Sun, 05 Oct 2008 17:46:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <DD74FBB8EE28D441903D56487861CD9D36950DF1@xxxxxxxxxxxxxxxxxxxxxx>
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: <20080926090857.GA3780@xxxxxxxxxxxxxxxxxxxxx><C50269BC.277C0%keir.fraser@xxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D36950080@xxxxxxxxxxxxxxxxxxxxxx> <D8078B8B3B09934AA9F8F2D5FB3F28CE08873AF355@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D36950DF1@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckfujH/cJPHbIutEd2CJwAX8io7RQABmyfAAF0ez3AAD2CqQAF2gjow
Thread-topic: [Xen-devel] Re: super page with live migration
>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx]
>Sent: Sunday, September 28, 2008 10:17 PM
>
>> I'm not familiar with restore proecss. Just a curious question.
>> Is it difficult or intrusive if we still keep 2MB frame even when
>> next 511 pages across batch boundary?
>
>We should optimistically allocate a 2MB frame if the rest of the batch
>we can see is contiguous.
>
>> Then when pages in
>> future batches come, we just copy them into previously
>> allocated 2MB frame covering them.
>
>Yes, they'll already have p2m table entries as a result of the earlier
>allocation.
>
>If the frames turn out not to be contiguous, we should
>allocate a buffer
>in the heap, copy the earlier pages into it, free the 2MB frame,
>allocate 4KB frames and copy the data in.
>
>> I'm just not sure about
>> the possibility for an individual 4k pseudo-phys page occuring
>> in early patch, which then result most following superpages
>> across batch boundary, and thus few 2MB frame can be
>> allocated in target side. Maybe this concern is not true due to
>> batch creation in save process? :-)
>
>The first iteration sends frames in-order, so it should be fine.
>

OK, same page then. I misunderstood your comments a bit
before.

Thanks,
Kevin

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

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