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