Howard Chu (hyc.delete@this.symas.com) on December 1, 2018 5:23 am wrote:
> 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.

I don't quite get it. Why parity is enough? Doesn't new tech has to be at least 1.5x to 2x denser in order to get a shot at replacement of old tech? Especially something like MRAM that seems to get an inherent disadvantage in write energy.

Or do you consider non-volatility an advantage?
I used to think about non-volatility as minor disadvantage, but in lights of all those new security threats around I am starting to think that may be disadvantage is not so minor.

> 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.
>