33. LA: OS Implications of Fast, Cheap, Non-Volatile Memory Flashcards
Let’s say we have a new NVRAM system (non-volatile RAM), which eliminates the need for RAM and a disk. What are 9 different significant aspects of OS design that we would have to reconsider if we were designing an OS for a device with this NVRAM system?
- Goodbye paging and 4k page sizes
- Unifying memory and file system protection
- Unifying memory and file system naming
- Installing, packaging, and launching apps
- Application faults
- Decoupling power cycles and reboot
- Reboot and data corruption
- New sleep states
- Moving data between machines
Explain why paging and 4k page sizes would need to be revisited with the invention of a NVRAM system.
Quite obviously, a device without both disk and memory no longer needs to move pages from disk to memory.
Remember our goal when choosing pages to evict? We wanted to make the system look like it had as much memory as the disk size, all of it as fast as memory. Mission accomplished!
This is an entire large OS subsystem that we can largely remove.
In addition, remember that we chose a page size for a variety of reasons that had a lot to do with the backing store.
When swapping, large pages minimize the size of kernel data structures while also amortizing the cost of disk seeks inside the swap file (or disk).
But we are no longer swapping.
Obviously, however, page size still plays a role in terms of hardware-aided address translation via the MMU and TLB, but because the NVRAM is byte-addressable we can experiment with new page sizes more suitable given this radical architectural change.
Some memory allocation and protection mechanisms even eliminate pages entirely.`
Explain why unifying memory and file system protection could be done with the invention of a NVRAM system.
Because we no longer have a separation between the memory and the disk, we need to consider how to unify the protection models.
Memory protection is hardware-enforced on page boundaries.
In contrast, file systems provide more coarse-grained (file-level) but richer protection semantics, including the idea of ownership, group permissions, permission inheritance (via directories), and even the flexibility provided by capability-based access control lists (ACLs) on some file systems.
Part of this richness, obviously, is because file system protection mechanisms are implemented in hardware, rather than software.
But now with a single large NVRAM chip serving as both memory and disk, we might want to consider a way to unify these.
At minimum, we have to ensure that the protection semantics provided by hardware when the NVRAM is used “like memory” are more closely-matched by what the OS provides in software when the NVRAM is used “like a disk”
Explain why unifying memory and file system naming can be done with the invention of a NVRAM system.
Another fundamental difference between memory and file systems we need to reconsider is the idea of address spaces and how virtual addresses are translated.
Address spaces essentially provide each process with a separate local name space - recall that a virtual address is meaningless without an address space to translate it inside, or alternatively without knowing what process is translating the virtual address.
In contrast, file systems provide a global name space: /path/to/foo is the same file regardless of which process is opening or accessing the file.
Unifying these two abstractions requires identifying and addressing this issue.
One approach is to move to single address space machines, which have been previously explored.
Explain why installing, packaging, and launching apps would need to be revisited with the invention of a NVRAM system.
Today, executing an app essentially transforms it from one form - on disk - to another - in memory.
This is the job of the ELF file loader during exec().
A single NVRAM chip replacing both the disk and memory makes this unnecessary, and apps can be distributed in their ready-to-run form, eliminating the job of the ELF loader.
Another big part of the OS gone!
Although you still need to consider how to reconcile the addresses the process wants to use with the NVRAM that’s available on the machine, but loadable libraries have approaches to doing this that could simplify the process.
This change also fundamentally alters how applications save state.
Currently processes have to write out to stable storage to save state and have developed elaborate and process-specific mechanisms for doing so.
A big chunk of non-volatile memory makes that unnecessary, and allows them to essentially be stopped and restarted in any state without any additional process support.
So this really completely eliminates the usual process of “starting up” and “shutting down” a process as we currently know it, with no impact on memory consumption. Cool!
Finally, NVRAM also makes it extremely easy to move process setups from machine to machine, stored exactly at any point in their execution.
Explain why application faults would need to be revisited with the invention of a NVRAM system.
At last, a downside!
One of the interesting side effects of NVRAM is that what used to be impermanent (RAM) is now permanent.
Starting up and shutting down processes isn’t done only to let the OS know that you are done using a particular program and allow its resources to be freed - it also creates a chance for the process to reload its memory contents forma known good starting point frozen in the ELF file.
This is particularly important if the process is restarting to recover from a fault.
So removing this capability entirely isn’t necessarily a great idea, since whatever state corruption led to the fault is now impossible to remove.
There are a few ways to address this without forcing processes back to storing state “on disk”.
One way is to have users create snapshots or checkpoints of the process at good states, which could be stored in the (very large) NVRAM and reverted to after failures.
Explain why decoupling power cycles and reboot would be possible with the invention of a NVRAM system.
Another interesting effect of the single large NVRAM chip is that power cycles no longer have to trigger a reboot.
IF the device loses power, (almost) all of its state is permanently stored on the NVRAM, with the exception being any register state associated with its execution at that precise instant.
(Although with a small amount of battery backup that could be written to the NVRAM after a sudden loss of power before the processor went offline.)
So the idea that power cycles need to trigger a reboot on wall-powered devices no longer holds.
On battery-powered devices the story is even simpler, since they already have ways to monitor their battery levels and don’t need to be unprepared for most power outages - with the exception being the user suddenly ripping the battery out!
Explain why reboot and data corruption would need to be revisited with the invention of a NVRAM system.
While this sounds like a plus, reboots for the OS can serve the same useful purpose as restarts do for processes:
the chance to reload potentially-corrupted state from a known good starting point.
So it probably makes sense to preserve some kind of reboot mechanism that can be triggered by users when needed that allows the OS to reinitialize state and recover from faults it may be unable to detect.
But again, there is no need for reboots to be coupled in any way to power cycles, since the “memory” never loses state.
Explain why new sleep states are possible with the invention of a NVRAM system.
The overhead of entering a low-power sleep state is now limited to the cost of unloading the process registers into the NVRAM and then powering down the processor.
On most mobile devices, the memory must either be moved to stable storage in order to be powered off - an expensive process - or kept in an active state to avoid losing contents, which consumes power.
Our new device avoids this entirely and can sleep both much more quickly and completely and power on much more rapidly.
Explain why moving data between machines would need to be revisited with the invention of a NVRAM system.
Given the mixed nature of the content on the NVRAM, it may become more difficult to move data between machines.
Part of this depends both on the protection and naming mechanisms adopted for a unified memory and disk storage device, as well as the ways that processes adapt to this change.
For example, if processes choose to begin bypassing the file abstraction and store data that is usually stored in files in memory - which is safe, since memory is permanent - it becomes impossible for users to move files from place to place.
As a concrete example, if iTunes starts storing all my MP3 content in memory, how do I reorganize (again, for the 12th time) my music collection?
There are no files to manipulate!
Or what if I want to move a picture to a thumb drive to show a friend?
But maybe file systems and files are dead and over anyway, and all data transfer in the future will take place through the cloud. Who knows.
