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] 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

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.


> Thanks,
> Kevin

Xen-devel mailing list