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: '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: Sun, 28 Sep 2008 14:51:58 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Sat, 27 Sep 2008 23:52:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <DD74FBB8EE28D441903D56487861CD9D36950080@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckfujH/cJPHbIutEd2CJwAX8io7RQABmyfAAF0ez3A=
Thread-topic: [Xen-devel] Re: super page with live migration
>From: Ian Pratt
>Sent: 2008年9月26日 18:18
>>> if it turns out that the contiguous stream of pseudo-phys addresses
>is broken in the next batch.
>Rather than shattering the 2MB frame, it would be better to copy the
>pages out into a heap-allocated buffer, free the 2MB frame, and then
>allocate order-0 pages and copy the data in.
>This avoids needlessly fragmenting xen's memory.

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? Then when pages in
future batches come, we just copy them into previously
allocated 2MB frame covering them. 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? :-)


Xen-devel mailing list