RE: [Xen-devel] what happens when a PoD page is touched?

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx]
> Sent: 17 May 2011 00:40
> To: Paul Durrant; Tim Deegan
> Cc: George Dunlap; xen devel
> Subject: RE: [Xen-devel] what happens when a PoD page is touched?
> 
> >
> > > -----Original Message-----
> > >
> > > I've not seen any slowdown on boot with any version of Windows
> until
> > > I go to actually do the balloon down...
> > >
> >
> > In that case I guess your slowdown is caused by touching the
> pages.
> IIRC you
> > will encounter a sweep every time you touch a pod page and the
> cache
> is
> > exhausted. The sweep should reap all zeroed pages and hopefully
> fill
> the cache
> > so the sweep should not be invoked too often. Try using the
> non-touching
> > allocator.
> >
> 
> So avoiding the sweep is the thing to do then?
> 

Yes. You clearly want to avoid the overhead of a sweep to populate pages that 
you're immediately going to hand back to Xen.

> Where does the sweep start? Does it sweep in physical address order
> from lowest address to highest? If I allocated some memory with a
> low physical address and zero'd it and then didn't touch it would
> that be found first?
> 

I can't remember off the top of my head. I think we sweep from low to high.

> 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 majority 
of cases. MmAllocatePagesForMdlEx() is available post 2k3-sp1 so it's really 
only XP that would be suffering sweeps anyway and you may be able to mitigate 
that by ballooning down in smaller chunks such that you fill the PoD cache just 
enough to avoid a sweep during in the next bunch of allocations.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel