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] map memory holes with same page

To: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] map memory holes with same page
From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Date: Mon, 23 May 2011 10:23:30 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: "James Harper \(james.harper@xxxxxxxxxxxxxxxx\)" <james.harper@xxxxxxxxxxxxxxxx>, "Keir Fraser \(keir@xxxxxxx\)" <keir@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 May 2011 02:25:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110523091307.GC12250@xxxxxxxxxxxxxxxxxxxxxxx>
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: <AEC6C66638C05B468B556EA548C1A77D01D5728C@trantor> <C9FD4F2B.1ABE7%keir.xen@xxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01D5728D@trantor> <291EDFCB1E9E224A99088639C4762022B37FC17D49@xxxxxxxxxxxxxxxxxxxxxxxxx> <20110523091307.GC12250@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwZKaFoUMsvjRJ3TAaqIlUfNxWwCAAAS9/w
Thread-topic: [Xen-devel] map memory holes with same page
> -----Original Message-----
> From: Tim Deegan
> Sent: 23 May 2011 10:13
> To: Paul Durrant
> Cc: James Harper; Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] map memory holes with same page
> At 09:42 +0100 on 23 May (1306143771), Paul Durrant wrote:
> > > -----Original Message-----
> > [snip]
> > >
> > > Should there be a performance impact if Windows tries to touch a
> > > page that I have previously given pack with
> decrease_reservation?
> > > Will that invoke the PoD sweep?
> > >
> >
> > No. The p2m entry will be 'invalid', not 'PoD'. IIRC the sweep
> should
> > only be invoked if the cache is exhausted when trying to fix up a
> PoD
> > entry.
> But yes, there will be a performance impact because all accesses to
> the missing page will be emulated by sending an ioreq to qemu, so it
> will run _very_ slowly.

Good point. That would explain why a hibernate would be slow vs. a crashdump 
(if it's going through and trying to compress ballooned out pages).


Xen-devel mailing list