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: "Paul Durrant" <Paul.Durrant@xxxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] what happens when a PoD page is touched?
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Tue, 17 May 2011 19:37:29 +1000
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 May 2011 02:38:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <291EDFCB1E9E224A99088639C4762022B37FC17A16@xxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwTpN+bajrHxxU3SuO3T+F6nhFaRAABS6hwAAApRtAAABGywAAdxYFwABR697AAADk6wA==
Thread-topic: [Xen-devel] what happens when a PoD page is touched?
> > Alternatively, I balloon down 1MB of memory at a time - if I could
> > set aside 1MB of memory that was filled with 0's and could somehow
> > tell xen to use that memory first then it might speed things up too
> > yes?
> >
> Why can't you just use an allocator that doesn't touch memory in the
> of cases. MmAllocatePagesForMdlEx() is available post 2k3-sp1 so it's
> only XP that would be suffering sweeps anyway

I can't guarantee that all the pages I hand back are clean, and testing
shows that a small number of them aren't. In theory, anything that cares
about the data in its pages (eg an encrypted FS) would have cleaned them
before handing them back to windows but I'd rather clean them first.

Is there a way to tell if a page is currently populated? That would
allow me to only clean populated pages.

> and you may be able to mitigate
> that by ballooning down in smaller chunks such that you fill the PoD
> just enough to avoid a sweep during in the next bunch of allocations.

I still can't quite get my head around why this happens at all... I
thought it would go like this:

1. Allocate 1MB of memory
2. Still under our limit so xen populates the pages when Windows clears
3. Hand them back to xen
4. Repeat

I'm doing that in a tight loop very early in boot. If I keep handing
back pages (and thus reducing my populated page count) why am I hitting
any PoD limit at all and invoking the page scavenging code? Windows
isn't doing anything else at this point, and even if it was, I'm the
boot driver so it has to wait for me before the boot can progress so
it's not like it would be consuming gigabytes of memory.



Xen-devel mailing list