Managing Volatile Memory with Memkind

  • Обзор
  • Ресурсы
  • Текст

Get an introduction to Memkind’s support for persistent memory and show how you can use it to manage volatile memory on your Intel® Optane™ DC persistent memory modules.

The memkind library supports the volatile use case of Intel Optane DC persistent memory modules and highlights the large capacities and cheaper-than-DRAM price points expected for these persistent memory products.

Resources:

Persistent memory developer resources: https://intel.ly/2UgS7KX

Visit the memking GitHub* Repo: http://bit.ly/2Jb7C1z

Read the article: https://intel.ly/2J8ExE9

Memkind GitHub site: http://bit.ly/2Ja4Idt

Memkind GitHub code examples: http://bit.ly/2JdETt8

Hi, I'm Kelly Lyon from Intel. In this video, I introduce Memkind's new support for persistent memory and show how you can use it to manage volatile memory on your Intel® Optane™ DC persistent memory modules.

The Memkind library supports the volatile use case of Intel Optane DC persistent memory modules and highlights the large capacities and cheaper than DRAM price points expected for these persistent memory products. This is not to be confused with memory mode.

Memkind, which operates in app direct mode, is a user extensible heat manager built on top of jemalloc. It manages different kinds of memory, kinds like high-bandwidth memory, interleaved pages, huge page tables, persistent memory, and even custom types.

With support from Intel engineers, Memkind has a new option called PMEM kind to expose persistent memory. There are several benefits applications see when using PMEM kind. First of all, applications have full control over data placement between DRAM and volatile memory stored on the persistent device.

Since applications can see them as separate pools, this creates a separate tier of volatile memory exposed by Memkind. Applications can then choose to place latency sensitive data onto DRAM and read only or bandwidth sensitive data onto the persistent memory space to optimize usage.

Under the hood, the PMEM kind is actually a temporary file on a DAX-enabled file system this file is memory mapped onto the applications virtual address space. Jemalloc then uses this address space to allocate objects, and the file is automatically deleted when the program terminates, giving the perception of volatility.

Using Memkind for managing data on persistent memory devices is easy thanks to the API calls made specifically for the PMEM kind. Here are three simple steps. Step 1, create the memory-mapped region. Memkind_create_pmem creates the PMEM kind memory in the directory specified.

Max_size defines the size of the memory-mapped file, and kind is your pointer to the memory-mapped region. Step 2, allocate memory from the memory-mapped region. Memkind_malloc creates size bytes of uninitialized memory of the specified kind. In our case, the kind will be PMEM kind.

Step 3, free allocated memory. Once you've used the memory you've allocated, you must remember to free it. Memkind_free releases the allocated memory reference to by pointer to make that space available again for future allocations. Two other useful calls are memkind_calloc and memkind_realloc.

Realloc changes the size of the previously allocated object. Calloc allocates the specified kind space for num objects, each of the size specified in byes. Examples showing these calls in action can be seen on the Memkind GitHub page, where you can also download the full API. Thanks for watching.

Возможность комментирования русскоязычного контента была отключена. Узнать подробнее.