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

[Matt Thomas <matt%3am-software.com@localhost>]

On Oct 17, 2013, at 10:41 PM, David Holland 
<dholland-tech%netbsd.org@localhost> 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.  
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.  

Indeed, it might be cheaper to avoid uvm_fault to map the pages
and just map them.  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.