David Kanter (dkanter.delete@this.realworldtech.com) on July 23, 2018 9:02 am wrote:
> In honor of our anniversary, I have a new article on Intel's 3DXP DIMMs:
>
> Intel will offer 3DXP-based DIMMs (previously codenamed Apache Pass) that use the DDR4 interface on the next-generation
> Cascade Lake server processor. The first DIMMs will be available in 128GB, 256GB, and 512GB capacities and
> work with a new software architecture for persistent memory. Intel and its partners have enabled the new persistent
> memory programming model for Java, Linux, VMware, and Windows and many customers are eagerly awaiting the
> non-volatile, high-capacity memory for in-memory databases and other applications.
>
> I also point out many of the areas Intel has been less than forthcoming,
> particularly around security and serviceability.
>
> As always - comments, questions, and feedback are appreciated.
>
> David

I've spent several weeks working with Intel to benchmark LMDB on Optane DIMMs, starting this past July. Unfortunately, we still don't have permission to discuss performance results. (But you can check out our results on Optane SSDs here http://www.lmdb.tech/bench/optanessd/ )

Some comments and bragging though:
LMDB Lightning Memory-Mapped DB works out of the box with all operating modes
of Optane DIMMs. Whether using the DIMMs configured as a raw block device, or
using regular file access through a filesystem, with or without DAX. All of
these modes were tested and It Just Works.

But, presenting Optane DIMMs as separate storage is not sensible, and IMO all
the work done at SNIA to create their PMDK (which we don't use) was wasted
effort.

It is a fact of computing that the size of work always grows to exceed the
available space. Even with 512GB NVDIMMs and terabytes of addressable
"RAM". What SNIA has done is allow people to use NVDIMMs as RAMdisks. Hello,
RAMdisks went out of style in the late 1980s, for good reasons. Primarily
because they require users to explicitly decide what portions of their data
to move onto RAMdisks, forcing them to leave other portions of their data
still on slower storage. The only sensible way to use finite RAM is as a cache
for (nearly) infinite secondary storage. And a cache should operate invisibly,
so there should be no need for special APIs like PMDK.

Personally I don't believe Optane DIMMs are going to replace DRAM, but tech
like STT-MRAM has a good shot, if they ever reach parity to DRAM density. So
we shouldn't be building software systems around the notion of mixed RAM/NVRAM
memory maps. We should assume that eventually we're going to have machines
with 100% NVRAM, and design accordingly. That means you want a kernel whose
pagecache manager knows how to reuse the hot contents of NVRAM after a reboot.
That's all you need, the rest of user space can go on without changing a single
line of code.