(lengthy) musings on nonvolatile memory

[Yoused]

I have been keeping an eye on a certain type of magnet memory that is looking more and more promising. It is coming close to DRAM/SRAM speeds while also pushing toward low power requirements and, unlike Flash, supports discrete data access (by bytes, not by blocks). It has the advantage of eliminating the DRAM refresh cycle, further reducing a system's power needs, and seems to have essentially limitless cycle endurance.

The one major downside, of course, is that its data is stored in magnetic domains, meaning that a compact device like a phone or MBA would require some kind of shielding to protect it from stray fields. I am not clear what the requirement would be like, but it might make a phone using this kind of memory heavier/thicker than what we are used to, and could make some types of accessories unusable. Wireless charging could be an issue.

But, if in a few years, it starts to penetrate the market in practical ways, (TSMC is working on developing two of the memory types), will we be ready for it?

If they get the speeds down and the densities up, this type of NVRAM could replace both Flash and DRAM at the same time. If you have a 512GB computer, that becomes both memory and storage. Which means that your device no longer has a sleep state that is different from the off state (other than that networking is not active during off state).

But what does this do to OS design? If your working RAM is unified with your storage memory, this creates all kinds of weird issues. When you install a program, the system will splat the original file into its native operating form, and loading a program becomes a simple matter of mapping it into a set of pages and jumping into it. Moreover, the environment of some applications could simply be stored as-is, and the program would be freed of the task of reconstructing its workspace. App loading would be absolutely instantaneous.

Data files would be a similar situation. They could just be mapped directly into memory, which is wonderful if you have a file that tolerates instant modification – some files might be better mapped into read-only pages when opened and remapped when written to, to prevent unintended damage.

All this makes the traditional file system obsolete, at least at the system volume local level. How a computer with unified storage/memory would be optimally organized remains an open question, but contemporary operating systems are just not ready to be ported to it.

And, of course, most storage is at least somewhat compressed. Some files will just not work right in the unified layout, yet copying them from stored content to another part of NVRAM seems like a waste of time. I am wondering if there is a compression scheme that could expand file data into a cache-like buffer and recompress it into a storage format in a randomly-accessible way. I can imagine a SoC that includes multiple units that would manage this transparently to a running process.

And, of course, there is the issue of programs crashing. The crash daemon has to be able to figure out what it must scrub before the program can be allowed to restart. Nuke-and-pave is obviously the easiest, but also the least efficient.

It seems like Apple is probably better positioned to handle this sort of transition, with their somewhat modular OS that can be ported more easily. I like to hope that they are already on top of this, so that when we get to the NVRAM revolution, they will be ready to make the most of it.

 

[leman]

Unification of RAM and disk storage at the logical level has been done decades ago with virtual memory, which is at the core of every modern OS. So physical unification of RAM and storage should mostly simplify the OS code (with caveats).

I also don't think that NVRAM would make filesystems obsolete — maybe some aspects of the filesystems having to do with them being optimized for block storage rather than byte storage. You still need a way to track and reference named, persistent (beyond the application instance lifetime) storage, and that is precisely the function of the filesystem. Maybe with NVRAM we can get new APIs such as RAM allocations that outlive the application, but that will come with additional complexity as the app needs to ensure consistency.

Right now, block storage (SSD/HDD) is merely the last level of the memory hierarchy. Unifying RAM and storage would compact the memory hierarchy, but it is likely that some aspects will merely move around. Already now Apple has patents that discuss allocation of cache slices as ephemerous "RAM" not backed by memory controller. So I can imagine that at least some of the transient memory allocations will be shifted closer to the SoC, retaining at least some aspects of the separation between the working set and the backing store.

 

[Yoused]

I also don't think that NVRAM would make filesystems obsolete — maybe some aspects of the filesystems having to do with them being optimized for block storage rather than byte storage.

The problem with "optmizing for byte storage" is actually worse with unified memory/storage. You want to be able to just map a file into a program's memory, because that is much faster and cheaper than copying, but a unix-like system has a whole lot of files, and many of them are very small. You could fit them into a small space, but then if the process wants a particulac file, it would get a 16K page with the file it wants along with the content of a bunch of other small files. This could be a security problem.

The obvious solution is to change the methodology so that the apps that use these small files get/modify them through a capability (object-like thing). It would be the logical way to go, but basically all of darwin would have to be rewritten to make it work. Not that that would necessarily be a bad thing.

 

[Roller]

The problem with "optmizing for byte storage" is actually worse with unified memory/storage. You want to be able to just map a file into a program's memory, because that is much faster and cheaper than copying, but a unix-like system has a whole lot of files, and many of them are very small. You could fit them into a small space, but then if the process wants a particulac file, it would get a 16K page with the file it wants along with the content of a bunch of other small files. This could be a security problem.

The obvious solution is to change the methodology so that the apps that use these small files get/modify them through a capability (object-like thing). It would be the logical way to go, but basically all of darwin would have to be rewritten to make it work. Not that that would necessarily be a bad thing.

I don't quite understand all the technical intricacies, but thanks for taking my mind off all the political craziness, if only for a little while!