Non-Volatile DIMMs To Ship This Year 63
Lucas123 writes "Both Viking and Micron plan to ship cards that combine DRAM and NAND flash on a standard DDR3 DIMM. The cards will have twice as much NAND flash as volatile memory. For example, the non-volatile DIMMs will come in capacities ranging from 4GB of DRAM to 16GB and 8GB of flash to 32GB of flash. Micron also sees its NVDIMM card being used as a storage tier, as cache for RAID systems, system check pointing, full system persistence, data logging, de-duplication and fast access to metadata. Without providing specifics, Viking said the NVDIMM cards will cost roughly a few hundred dollars each, more than a standard DDR3 DIMM module but still inexpensive enough for server and storage admins to consider for boosting application performance."
Re:I don't get it... (Score:4, Interesting)
The point is not read caching, it's write buffering. Essentially RAM-speed (both number of transactions per second and bandwidth) writes as long as working set is sufficiently small while maintaining the promise of persistence.
Weakness is that buggy hardware or software might be capable of wider variety of modes of corruption to the data than with devices that look like disk to the OS. Also, in order OSes to benefit of this kind of memory, they must be able to recover non-flushed data after a crash, and in order to reduce overheads, OSes must be capable of allocating this sort of memory for dirty storage buffers (unless all memory in a system is such).
Re:I don't get it... (Score:5, Interesting)
There are a few suggestions already, but here are some more.
If your system is doing nvram synchronization of system ram, that means that a suspend to nvram is almost instant, and since the copy from the nvram does not need to go through the disk subsystem on your motherboard (northbridge or sata controller) but can be handled directly by the system memory itself, it can significantly improve boot up time. I don't think it would be instantaneous, but it very well may be within a ping round trip for a web server to come up, process the ping and actually respond, perhaps go back to suspend until there is real traffic to attend to. (Though responding to a ping might be relegated to an improved ethernet controller, why start up the main system for a simple icmp request.) As a result of not having this system on when there is no actual traffic to handle means that you can save power even more than doing dynamic processor clock adjustments.
Alternatively if you are doing write buffering you can reserve a portion of your buffer for boot up system files that can load into memory on a cold start, so you don't have to wait for the hard drive to spin up from cold, and again is faster than plugging a usb3.0 memory stick into a usb port on the computer. Optimize the collection of files to be loaded there and you may be able to get a complete boot off the memory without touching the hard drive.
Extended logging into nvram so that the system can capture what is going on when it can't write/read the hard drive or flash drive because of a problem on the system board.
As prices go down, diskless laptops become completely diskless with apparent instant-on, instant suspend capabilities. Possibly even shutting down the system when there is no I/O happening. (GPUs on video cards could easily take over things like updating the clock on the display, shutting down the display after a cetain period of idle time, or even when sensing the laptop has been closed.)
Write buffering means that storage is journaled without having to do journaling on the hard drive. A side effect is that in a raid5 array if a physical drive fails during a write, you can redistribute what was written, and so long as you maintain two or more physical drives, can rebuild the array contents to maintain redundancy on the off chance that another drive fails before you get the first rebuilt. (something like that is going to take additional coding in the server OS, and means that the raid5 is going to be software rather than hardware based.)
Those are just a few ideas off the top of my head.
Re:I don't get it... (Score:4, Interesting)
That would be extemely dependent on the hardware setup, and thus isn't workable since each system designer would have to build in such features not just in a standard manner, but in a manner that wasn't easily circumvented. Therefore, that's not something you are going to ever see.
Once the physical hardware is accessed, that's pretty much the point where the strength of encryption relies upon static protections.
Vampire taps into the Disk Drive's cables can easily prevent the disks from being erased (since we aren't likely to see disks with built in deadman switches...)
A software deadman's switch-like process is likely your best bet, and about the only thing you can really do at that point is to increase the polling frequency of the switch. So instead of checking the 'I'm alive' signal every 10 minutes, it would check it every 10 seconds.
Not that there aren't precautions a system designer can take, but for non-custom hardware designed specifically with anti-tamper features in mind, it's just going to be an academic exercise because encryption software must always strike a balance between security and accessibility. What's the point of data if you can't access it when you need to? Any increase in 'tripwires' that locks up the data will decrease in the data's accessability to the person who should have access to it.
Embedded systems do this already (Score:4, Interesting)
I was thinking of this very scenario not too long ago. Many ARM (and other archs) embedded microcontrollers support external memory busses which can have a mix of SRAM, SDRAM and Flash. The flash can hold a binary image and/or a flash file system. I imagine the combo DIMMs would provide you with a similar setup, allowing a flash file system along with standard DDR RAM on the same memory controller.
I must admit that I can't wait to see performance numbers for read speeds. Using it as a frequently written cache is a stupid idea as you will wind up wearing down the flash BUT if its used to cache frequently read files then you really have something. What would be interesting is if you could use execute in place [wikipedia.org] to run software directly from the flash. There could be a mechanism where the flash disk is mapped into the file system. The OS or the user can decide which files can be loaded from disk to flash cache and a link or pointer now points to the flash instead of the disk making it transparent. Loading a program could be done in a few seconds. The OS could even map system files to the flash so booting could take seconds and energy saving suspends or shutdowns can resume in a second or so.
I imagine it would be a great boost for gaming, probably the biggest (and most likely target) market for these DIMMs. Games would benefit greatly from the break neck load speeds brought about by having the game already in memory. Gigabytes of game files can be loaded into flash and you can jump right into the game. Game save states could be loaded into flash and instantly recalled. Half life brought us the continuous game experience where there are brief load points between sections instead of load screens. Now that can be turned into continuous game play as all game data is already in a portion of main memory.
I think they might not benefit much else, maybe video editing but I think you would need over 100GB of flash storage for it to be useful. Using flash might not be the best idea but its the cheapest highest capacity non volatile memory we have at the moment. CellularRAM (PSRAM) and MRAM are other contenders but capacity and availability are an issue. MRAM is still in development and PSRAM is available but currently its suck at 16MB capacities.
And lastly, people assuming your encryption keys could be pilfered, the flash will not be used as RAM. It can't because Flash can't be written to on a per address basis like RAM (BUT MRAM and PSRAM can). But if you suspend by writing memory contents verbatim to flash, then you have a problem. My guess would be it might be possible to partition the memory so sensitive RAM contents would be discarded. Its up to the OS makers to implement these mechanisms. I imagine Linux and the BSD's would be most concerned about these potential security pitfalls and ensure this does not happen. I would like to think both Microsoft and Apple would be smart enough to also avoid such a glaring security hole. Maybe we can have a memtest like utility either in ROM or disk that zeros out the FLASH as a boot option.