Re: [Xen-devel] windows tmem

[James Harper <james.harper@xxxxxxxxxxxxxxxx>]

> >
> > 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.

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.

Thanks

James


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