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.
-George
On Mon, Feb 28, 2011 at 1:41 PM, Paul Durrant <Paul.Durrant@xxxxxxxxxx> wrote:
> James,
>
> Indeed, zero page sweeping is code inside xen that runs if the PoD cache is
> exhausted. It refills the cache with pages that are zeroed out (replacing
> them with pod entries in the p2m). Your initial balloon down may well be slow
> if you (or the windows kernel) touches the page before you hand it back to
> xen, since the pod code will have to populate each page in the p2m as it is
> touched.
>
> Paul
>
>> -----Original Message-----
>> From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx]
>> Sent: 28 February 2011 12:29
>> To: Paul Durrant; George Dunlap
>> Cc: xen devel
>> Subject: RE: [Xen-devel] PoD in other (not GPLPV) drivers
>>
>> >
>> > I actually have plans to push it earlier because we balloon down
>> quite
>> late at
>> > the moment (off the back of the START IRP in the top level bus
>> driver). We are
>> > reliant upon zero-page sweeping code in Xen to save us from guest
>> crashing up
>> > to that point.
>> >
>>
>> I've modified GPLPV to balloon down at DriverEntry time, which seems
>> to be early enough. Prior to that, memory=128 and maxmem=1024 was
>> enough to cause a crash under 2008, basically as soon as I tried to
>> access the registry in DriverEntry. My drivers are using WDF and are
>> therefore loading after the KMDF framework which is going to use
>> additional resources. My backup plan is to write a WDM driver that
>> loads even earlier than that and does the allocation, passing it to
>> the real PV drivers later on, although my concern there is that
>> Windows may not like memory allocated by one driver being freed by
>> another...
>>
>> I've never heard of 'zero-page sweeping code' before... is that a
>> way of xen reallocating a previously touched page if it contains all
>> 0's if we want a page beyond our allocation limit? That might
>> explain why my initial balloon down is so slow! I can tell windows
>> to not zero pages before it gives them to me when I do the initial
>> balloon down... what are your thoughts on that? Although it's
>> unlikely at boot time, in theory they could contain sensitive
>> information and I'm supposed to zero them before handing them back
>> to xen according to the docs.
>>
>> James
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home