| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: super page with live migration
|
To: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] Re: super page with live migration |
|
From: |
"Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx> |
|
Date: |
Sun, 28 Sep 2008 15:16:37 +0100 |
|
Cc: |
Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> |
|
Delivery-date: |
Sun, 28 Sep 2008 07:17:25 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<D8078B8B3B09934AA9F8F2D5FB3F28CE08873AF355@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AckfujH/cJPHbIutEd2CJwAX8io7RQABmyfAAF0ez3AAD2CqQA== |
|
Thread-topic: |
[Xen-devel] Re: super page with live migration |
> 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.
Ian
> Thanks,
> Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home