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] what happens when a PoD page is touched?

To: "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] what happens when a PoD page is touched?
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Wed, 18 May 2011 15:20:28 +1000
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 May 2011 22:21:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01D5718E@trantor>
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: <AEC6C66638C05B468B556EA548C1A77D01D57078@trantor><20110516083905.GP24068@xxxxxxxxxxxxxxxxxxxxxxx><291EDFCB1E9E224A99088639C4762022B37FC178F9@xxxxxxxxxxxxxxxxxxxxxxxxx><AEC6C66638C05B468B556EA548C1A77D01D570EB@trantor><291EDFCB1E9E224A99088639C4762022B37FC178FA@xxxxxxxxxxxxxxxxxxxxxxxxx><AEC6C66638C05B468B556EA548C1A77D01D570F6@trantor><291EDFCB1E9E224A99088639C4762022B37FC17A16@xxxxxxxxxxxxxxxxxxxxxxxxx><AEC6C66638C05B468B556EA548C1A77D01D5714A@trantor><BANLkTinN-1sxKT5kbSbHG-gOMipundQSRQ@xxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01D5718E@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwUkohJs3qosyLbTtiDW2ZT9heDogAhAoAQAADo/PA=
Thread-topic: [Xen-devel] what happens when a PoD page is touched?
> > The exception to this would be the case where you're allocating N
> > pages, where N > (used_pages - total allocation).
> >
> > I guess try allocating fewer pages before returning them to Xen, and
> > seeing if that helps at all.
> I tried returning 64KB at a time (eg 16 pages) instead of 1MB but it
> doesn't improve things. Xen should just repopulate every page I
> with the pages I just returned and things should fly along but it's
> working that way.
> Just taking a step back for a sec, maybe I'm doing something else
> My balloon down code allocates memory from Windows with
> MmAllocatePagesForMdlEx then hands the pages to Xen with
> XENMEM_decrease_reservation. Is that all I need to do? I notice that
> Linux makes a call to set_phys_to_machine(INVALID_P2M_ENTRY) for each
> page, even in the hvm case. Is that some function I need to mirror too
> or is that just internal Linux housekeeping and not required under
> Windows?

Hmmm... I think I'm chasing the wrong problem here. I measured time
taken to allocate the memory, and then time taken to decrease
reservation, and the decrease reservation time is 6x longer than the
memory allocation time (as measured by the
TSC/KeQueryPerformanceCounter). That approximately equates to 18 seconds
to allocate and scrub 3.5GB of memory, and 111 seconds in calls to
decrease reservation. This measurement is consistent across a few boots
so I assume it's not an artefact of using the TSC under a virtualised


Xen-devel mailing list