156
• Can use the native latencies of persistent memory, which may be
slower than DRAM but are faster than non-volatile memory express
(NVMe) solid-state drives (SSDs).
Background
Applications manage different kinds of data structures such as user data, key-value
stores, metadata, and working buffers. Architecting a solution that uses tiered memory
and storage may enhance application performance, for example, placing objects that
are accessed frequently and require low-latency access in DRAM while storing objects
that require larger allocations that are not as latency-sensitive on persistent memory.
Traditional storage devices are used to provide persistence.
Memory Allocation
As described in Chapters 1 through 3, persistent memory is exposed to the application
using memory-mapped files on a persistent memory-aware file system that provides
direct access to the application. Since malloc() and free() do not operate on different
types of memory or memory-mapped files, an interface is needed that provides malloc()
and free() semantics for multiple memory types. This interface is implemented as the
memkind library (http://memkind.github.io/memkind/).
How it Works
The memkind library is a user-extensible heap manager built on top of jemalloc, which
enables partitioning of the heap between multiple kinds of memory. Memkind was
created to support different kinds of memory when high bandwidth memory (HBM) was
introduced. A PMEM kind was introduced to support persistent memory.
Different “kinds” of memory are defined by the operating system memory policies
that are applied to virtual address ranges. Memory characteristics supported by
memkind without user extension include the control of non-uniform memory access
(NUMA) and page sizes. Figure 10-1 shows an overview of libmemkind components and
hardware support.
Chapter 10 Volatile Use of persistent MeMory
• Can use the native latencies of persistent memory, which may be
slower than DRAM but are faster than non-volatile memory express
(NVMe) solid-state drives (SSDs).
Background
Applications manage different kinds of data structures such as user data, key-value
stores, metadata, and working buffers. Architecting a solution that uses tiered memory
and storage may enhance application performance, for example, placing objects that
are accessed frequently and require low-latency access in DRAM while storing objects
that require larger allocations that are not as latency-sensitive on persistent memory.
Traditional storage devices are used to provide persistence.
Memory Allocation
As described in Chapters 1 through 3, persistent memory is exposed to the application
using memory-mapped files on a persistent memory-aware file system that provides
direct access to the application. Since malloc() and free() do not operate on different
types of memory or memory-mapped files, an interface is needed that provides malloc()
and free() semantics for multiple memory types. This interface is implemented as the
memkind library (http://memkind.github.io/memkind/).
How it Works
The memkind library is a user-extensible heap manager built on top of jemalloc, which
enables partitioning of the heap between multiple kinds of memory. Memkind was
created to support different kinds of memory when high bandwidth memory (HBM) was
introduced. A PMEM kind was introduced to support persistent memory.
Different “kinds” of memory are defined by the operating system memory policies
that are applied to virtual address ranges. Memory characteristics supported by
memkind without user extension include the control of non-uniform memory access
(NUMA) and page sizes. Figure 10-1 shows an overview of libmemkind components and
hardware support.
Chapter 10 Volatile Use of persistent MeMory