Re: storage-class memory (was: Re: state of XIP?)
On Fri, Oct 18, 2013 at 09:15:33AM -0700, Matt Thomas wrote: > >> 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. > > Huh? I'm was talking about an executable's .data section. > Since we are talking about execute-in-place. If you support MAP_COPY, then you have to support copying-on-write on the filesystem's access path to file pages. If the file page is something physically significant, this becomes problematic. If you don't support MAP_COPY but only MAP_PRIVATE, then all that matters is the mapping, so all you have to do is enter it into the pmap as readonly when you fault it in, and it shouldn't matter what kind of page it is underneath. But, as I've said, while I've written more than one VM system I don't know that much about UVM specifically, so maybe there are issues I'm not thinking of. -- David A. Holland dholl...@netbsd.org
Re: storage-class memory (was: Re: state of XIP?)
On Oct 18, 2013, at 1:06 AM, David Holland wrote: >> 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. Huh? I'm was talking about an executable's .data section. Since we are talking about execute-in-place.
Re: storage-class memory (was: Re: state of XIP?)
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 dholl...@netbsd.org
Re: storage-class memory (was: Re: state of XIP?)
On Oct 17, 2013, at 10:41 PM, David Holland 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.
storage-class memory (was: Re: state of XIP?)
On Tue, Oct 15, 2013 at 12:17:30AM -0700, Matt Thomas wrote: > On Oct 14, 2013, at 11:41 PM, David Holland wrote: > > Did uebayasi@'s XIP work get finished/committed? Which things does it > > work with? And (other than UTSL) where am I supposed to look to find > > out more? > > It was not committed since core felt that it needed too many kludges > to properly work. That's kind of a shame. While I understand it was written with the intent of supporting direct execution from NOR flash to save RAM on small devices, there's another case where it would be useful. "Storage-class memory" is a catchall term for several different proposed or experimental storage media that share a number of common properties: - they are nearly as fast as DRAM - they are much faster than flash - they are expected to be much larger per unit than DRAM - they have markedly better wear profiles than flash - they are expected to, eventually, become competitively priced - and they are persistent. The type most commonly cited is phase-change memory; memristors are another. It is not clear yet whether these will take off or whether (individually or collectively) they'll be the next magnetic bubble memory. There are also a number of unresolved problems pertaining to actually accessing these things usefully, and it remains unclear whether these materials will really be memory-mapped or will end up inside SSDs like flash. However, things have reached the stage where hardware vendors are interested in addressing these issues, and it's looking pretty likely that at least one of these schemes will make it at least to the point of shipping first-generation devices. Because of the low access latencies of these materials, reading from them into RAM is both more or less pointless and also a substantial waste of time. Instead, you'd like accesses to go straight to the hardware, with the hardware's pages mapped directly into user process memory. And hence, execute-in-place. Or more accurately, mmap-in-place, as one would want to be able to read. There's even a fairly substantial amount of interest in some quarters in writing via mmap, despite all the problems that entails. Furthermore, for non-mapped I/O one still wants reads and writes to go directly to the hardware pages without passing through cache pages in between. This is something I think NetBSD should be pursuing, because there's a decent chance of at least some hardware materializing and it would be unfortunate to be caught flat-footed. So. 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. (There is a second and more or less separate class of problems pertaining to buffers and file system metadata, but at least to begin with I think a SCM-aware file system can just ignore the buffer cache. Running ffs on a memory-mapped SCM device is a thornier issue we can probably defer.) -- David A. Holland dholl...@netbsd.org
Re: state of XIP?
On Tue, Oct 15, 2013 at 4:17 PM, Matt Thomas wrote: > > On Oct 14, 2013, at 11:41 PM, David Holland wrote: > >> Did uebayasi@'s XIP work get finished/committed? Which things does it >> work with? And (other than UTSL) where am I supposed to look to find >> out more? It is still WIP. See [1] and/or some discussions on tech-kern@. > It was not committed since core felt that it needed too many kludges > to properly work. The biggest reason XIP needs kludges is that UVM is too vnode+pagecache centric. [1] http://www.netbsd.org/~uebayasi/bsdcan-2010-xip.pdf
Re: state of XIP?
On Oct 14, 2013, at 11:41 PM, David Holland wrote: > Did uebayasi@'s XIP work get finished/committed? Which things does it > work with? And (other than UTSL) where am I supposed to look to find > out more? It was not committed since core felt that it needed too many kludges to properly work.
state of XIP?
Did uebayasi@'s XIP work get finished/committed? Which things does it work with? And (other than UTSL) where am I supposed to look to find out more? -- David A. Holland dholl...@netbsd.org
