SNIA NVM Summit: NVDIMMs, Programming Models and Next-Generation Non-Volatile Memory

January 30, 2015

Author: Stephen Bates (@stepbates)

On January 20, 2015, I had the pleasure of attending the SNIA NVM Summit in San Jose, California. This was a great event, and kudos to SNIA and Intel for putting it together. The event was very well attended by a who’s who of the NVM world.  There were a lot of great panels and presentations covering three main themes:SNIA

1.   NVDIMMs. NVDIMMs have been around for some time but have had issues with motherboard compatibility and OS support. It is clear that, while issues still remain, support is improving. I will be doing a more in-depth blog on NVDIMMs soon, where I will delve into them in a lot more detail and compare them to current alternatives, such as our Flashtec NVRAM card.

2.  Next-Generation NVM (NG-NVM). I have a mantra ;-). Let’s stop thinking about NVM as fast storage and start thinking about it as (slow) memory! This mantra has a lot of implications for how systems talk to NVM, and SNIA called out some of these at the summit:

a. NG-NVM will be byte-addressable and will not require erasure before writing.
b. NG-NVM will have more symmetric read/write times.
c. NG-NVM will be much faster to access than NAND flash.

These three items have huge implications for how we should talk to it versus how we talk to NAND flash today. Again I will be delving into this in more detail in an upcoming blog.

3.  NVM Programming Models. SNIA have been at the forefront of determining how we should talk to NG-NVM. They realize there are major things that have to change in operating systems in order to support NVM as main memory. OS life cycles can be very slow, so we need to be working on this topic now to be ready for this memory in 2-3 years time. For example:

a. Non-volatile main memory implies that memory corruption survives a power cycle. How do we avoid an infinite cycle of “blue screens of death”?
b. If power is lost, how do we ensure the system is restored to a clean state upon reboot?
c. When we write to non-volatile main memory how do we determine if the write has made it to the medium (as opposed to some level of cache)?

There is a whole pile of code starting to appear online related to this effort. Here are some good examples to get you started:

a. PMEM library. A suite of tools for working with persistent main memory.
b. Linux DAX kernel extensions.  Tools to support treating sections of main memory as a block device (to allow for FS addition). Also has EXT4 support hooks for persistence.
c. Linux PMFS.  A file-system for persistent memory that adds code to ensure writes can be committed to the medium.

All in all it was a very good day. It is reassuring to see that the industry recognizes that NVM will be changing over the next decade and systems and software will need to change to take most advantage of it. Many attendees believe we are at a very exciting point for NVM. I tend to agree and look forward to being part of the adventure!

Other Posts By This Author

facebooklinkedinmail



Leave a Reply

Your email address will not be published. Required fields are marked *


six × 4 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>