>
> Just for the public record: I believe that I have upstreamed all of
> the PoD fixes and improvements that we had in the XenServer tree with
> one exception: There are a series of patches to improve the "emergency
> zero-page sweep" behavior in Xen, particularly for pretty large
> (>24GiB) guests. This is because:
> * They were really ugly; hacks upon hacks, not suitable for
upstreaming
> * As far as I know, they're performance enhancements only, not
correctness
> ones.
>
> It doesn't sound to me like the zero-page sweeps should be involved in
> your issue, James. But if you (or anyone) would like the patches, I'd
> be happy to send them along for you to try. (And for the shy, or
> archaeologists looking at this long after I'm gone from Citrix, they
> can be found on the XenServer source ISOs.) I'm not sure they'll
> apply cleanly to 4.1, but that code hasn't had a lot of changes, so
> you should be able to work out how they apply.
>
> As part of my work to port XenServer to 4.1, I'm going to rewrite the
> patches, and I'll upstream them at that time.
>
Even without pre-zeroing the memory under Windows, it is still pretty
slow doing the initial balloon down. Even though I ask windows not to
zero fill the page (therefore populating it), windows may still be
touching it though. But even then I give it straight back to xen so in
hindsight I think the zero page sweep shouldn't get invoked.
For testing I'm trying some pretty extreme numbers though, eg
maxmem=16384, memory=512, so ballooning down 15.5GB of memory is never
going to be that fast. I now suspect that the delay is in the Windows
API. When I balloon down during normal runtime it is about 10x slower
than ballooning up.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home