Re: [Xen-devel] windows tmem

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx]
> Sent: 28 May 2013 09:58
> To: Paul Durrant; xen-devel@xxxxxxxxxxxxx
> Subject: RE: windows tmem
> 
> > >
> > > Do any of the Windows PV drivers make use of tmem in any way? I'm
> > > exploring how I could integrate this into GPLPV... so far I'm thinking of 
> > > a
> > > filesystem filter that detects pagefile reads and writes and redirects 
> > > them
> > > to tmem where appropriate.
> > >
> >
> > I'd mulled it over a while ago for the Citrix PV drivers but failed to 
> > really find
> a
> > usecase. I agree that pagefile *would* be a good usecase but to detect
> what
> > was pagefile I suspect we'd need a filter driver somewhere fairly high up
> the
> > storage stack and I didn't really fancy get into that at the time.
> >
> 
> I've just been dipping my toe in the windows fs filters and am finding them
> quite simple to deal with, so a straightforward implementation could be very
> easy. Detecting if the file is a pagefile is easy enough, there is a call to 
> query
> that (although it has some IRQL and errata limitations).
> 
> The one thing I'm not sure about is if windows provides a way to know that
> the page is done with. In theory, I would divert a write to tmem, then divert
> the subsequent read from tmem, and the read would signify that the page of
> memory could be removed from tmem, but that doesn't necessarily follow. I
> haven't solutions for the following:
> 
> . differentiating pagefile metadata writes from actual page writes. Eg if the
> swapfile was grown on the fly (windows does this) then windows would
> presumably update the signature of the swapfile, and this signature is likely
> undocumented. I suspect actual page writes will have particular buffer
> characteristics so maybe this isn't going to be too difficult.
> 
> . windows could optimistically write a page out during periods of idle io, 
> even
> though the page is still in use, and then later throw the memory page out if
> required, but the application the memory belongs to could be unloaded
> before then so there may be a write but never a read.
> 
> . windows could read a page back into memory, later throw the memory
> page out, and then still expect the pagefile to hold the data. I imagine this
> sort of behaviour is documented nowhere and even if I prove that a write is
> always later followed by exactly one read, this isn't guaranteed for the
> future.
> 
> A less risky implementation would just use tmem as a write-thru cache and
> then just throw out old pages on an LRU basis or something. Or discard the
> pages from tmem on read but write them back to disk. It kind of sucks the
> usefulness out of it though if you can't avoid the writes, and if windows is
> doing some trickery to page out during periods of low io then I'd be upsetting
> that too.
> 

This sounds a lot less fragile and the saving on reads to the storage backend 
could still be significant.
 
> Anyway I have written a skeleton fs filter so I can monitor what is going on 
> in
> better detail when I get a few minutes. Later versions of Windows might
> make use of discard (trim/unmap) which would solve most of the above
> problems.
> 
> There do seem to be some (windows equivalent of) page cache operations
> that could be hooked too... or else the api callback naming is leading me
> astray.
> 

Sounds interesting. Presumably, if you can reliably intercept all IO on a 
pagefile then I guess you could use tmem as a write-back cache in front of 
doing your own file i/o down the storage stack, as long as you could reliably 
flush it out when necessary. E.g. does windows assume anything about the 
pagefile content on resume from S3 or S4?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel