Re: storage-class memory (was: Re: state of XIP?)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Oct 18, 2013 at 12:34:24AM -0700, Matt Thomas wrote:
 > > If the XIP code is not mergeable, what's entailed in doing a different
 > > implementation that would be? Also, is the getpages/putpages interface
 > > expressive enough to allow doing this without major UVM surgery? For
 > > now I'm assuming a file system that knows about storage-class memory
 > > and can fetch the device physical page that corresponds to any
 > > particular file and offset. ISTM that at least in theory it ought to
 > > be sufficient to implement getpages by doing this, and putpages by
 > > doing nothing at all, but I don't know that much specifically about
 > > UVM or the pager interface.
 > 
 > IMO, no, getpages interface is not sufficient.  You also have the 
 > problem that the pages to be mapping are not "managed" pages.  

Ugh.

 > Additionally, you know these pages are almost certainly going to
 > be physically contiguous so you really to use large page sizes to
 > map them.  So you don't want UVM allocating pages nor do you want
 > to deal with unified buffer cache.  

Who says they're going to be physically contiguous? It would be nice
if they are, for that reason, but we're mapping files, not a device;
it's up to the FS to allocate intelligently and it doesn't necessarily
happen. Plus, if I map a 4M (or whatever appropriate size) region from
a single contiguous source, hopefully this will result in a superpage
mapping independently of what the underlying material is.

These are *supposed* to be UBC pages though; they're file data and
it's important for read(2) and write(2) operations to maintain
consistency with mappings.

It seems like what's wanted is to give UVM the page instead of having
it allocate one; but again, I don't know that much about UVM on the
inside.

 > Indeed, it might be cheaper to avoid uvm_fault to map the pages
 > and just map them.

Probably, but faulting them has to work so this is probably an
independent issue.

 > The only problem is marking data as copy-on-write
 > but again these pages aren't managed so the current COW code won't
 > be happy.

We shouldn't have to care about that unless we want to move to
MAP_COPY from MAP_PRIVATE.

-- 
David A. Holland
dholland%netbsd.org@localhost