[lkml]   [2019]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/4] Allow persistent memory to be used like normal RAM
Keith Busch <> writes:

> On Thu, Jan 17, 2019 at 11:29:10AM -0500, Jeff Moyer wrote:
>> Dave Hansen <> writes:
>> > Persistent memory is cool. But, currently, you have to rewrite
>> > your applications to use it. Wouldn't it be cool if you could
>> > just have it show up in your system like normal RAM and get to
>> > it like a slow blob of memory? Well... have I got the patch
>> > series for you!
>> So, isn't that what memory mode is for?
>> Why do we need this code in the kernel?
> I don't think those are the same thing. The "memory mode" in the link
> refers to platforms that sequester DRAM to side cache memory access, where
> this series doesn't have that platform dependency nor hides faster DRAM.

OK, so you are making two arguments, here. 1) platforms may not support
memory mode, and 2) this series allows for performance differentiated
memory (even though applications may not modified to make use of

With this patch set, an unmodified application would either use:

1) whatever memory it happened to get
2) only the faster dram (via numactl --membind=)
3) only the slower pmem (again, via numactl --membind1)
4) preferentially one or the other (numactl --preferred=)

The other options are:
- as mentioned above, memory mode, which uses DRAM as a cache for the
slower persistent memory. Note that it isn't all or nothing--you can
configure your system with both memory mode and appdirect. The
limitation, of course, is that your platform has to support this.

This seems like the obvious solution if you want to make use of the
larger pmem capacity as regular volatile memory (and your platform
supports it). But maybe there is some other limitation that motivated
this work?

- libmemkind or pmdk. These options typically* require application
modifications, but allow those applications to actively decide which
data lives in fast versus slow media.

This seems like the obvious answer for applications that care about
access latency.

* you could override the system malloc, but some libraries/application
stacks already do that, so it isn't a universal solution.

Listing something like this in the headers of these patch series would
considerably reduce the head-scratching for reviewers.

Keith, you seem to be implying that there are platforms that won't
support memory mode. Do you also have some insight into how customers
want to use this, beyond my speculation? It's really frustrating to see
patch sets like this go by without any real use cases provided.


 \ /
  Last update: 2019-01-17 18:20    [W:0.099 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site