There are several storage class memories that are nearing commercialization. Intel is betting big on at least one of them. Most technologies in this class are orders of magnitude faster and have orders of magnitude better endurance than flash memory, while being only slightly slower the DRAM, yet non-volatile.<p>It is plausible that with another layer of in-package cache they could eliminate DRAM altogether, replacing it with ultrafast NVM. Imagine the resume/suspend speed and power savings of a machine whose state is always stored in NVM.
I've heard predictions that a significant portion of new x86 servers will be using non-volatile memory within the new 5-7 years.<p>Memory is becoming the new disk. This could have major security implications, as memory contents are unencrypted in general.<p>Fortunately, Intel CPUs will have hardware support to encrypt SGX enclaves. Perhaps that support can be used for general memory access as well.
Computing really hasn't figured out how to handle non-volatile memory as yet. It's almost always used to emulate rotating disks, with file systems, named files, and a trip through the OS to access anything. Access times for non-volatile memory are orders of magnitude faster than disk access times, so small accesses are feasible. But that's not how it's treated under existing operating systems.<p>There are alternatives. Non-volatile memory could be treated as a key/value store, or a tree, with a storage controller between the CPU and the memory device. With appropriate protection hardware, this could be accessed from user space through special instructions. That's what I though this article indicated. But no. This is just better cache management for the OS.
Very interesting! It's always fun to see "external" development in the general field of computer architecture affect low-level stuff like a CPU's cache and memory subsystems.<p>It wasn't super-easy to figure out <i>who</i> in the grand ecosystem view of things is going to have to care about these instructions, but I guess database and OS folks.<p>Also, if the author reads this, the first block quote with instruction descriptions has an editing fail, it repeats the same paragraph three times (text begins "CLWB instruction is ordered only by store-fencing operations").
Isn't there a higher risk of data loss, if your "hard drive" is 100% memory mapped - all it would take is one buggy kernel driver writing to an invalid pointer or memset'ing the whole thing to 0?
Support for non-voltile memory needs to be added to Linux. For example, one should be able to map the non-volatile memory into user space and directly access it. There needs to be some BIOS-OS interaction so that the OS doesn't treat the non-volatile memory as general memory (for the likely case where only some of the memory is non-volatile).
Alternatively, the non-volatile memory should be usable as a block device.<p>The non-volatile memory needs a layer of RAID-like volume management. For example, when you transfer the memory from one system to another, there should be a way to determine that the memory is inserted in the correct slots (remember there is RAID like interleaving/striping across memory modules).
How to solve the context switch overhead issue: <a href="https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript" rel="nofollow">https://www.destroyallsoftware.com/talks/the-birth-and-death...</a>