13
• Data on persistent memory is instantly available, that is:
• Data is available as soon as power is applied to the system.
• Applications do not need to spend time warming up caches. They
can access the data immediately upon memory mapping it.
• Data residing on persistent memory has no DRAM footprint
unless the application copies data to DRAM for faster access.
• Data written to persistent memory modules is local to the system.
Applications are responsible for replicating data across systems.
Platform Support for Persistent Memory
Platform vendors such as Intel, AMD, ARM, and others will decide how persistent
memory should be implemented at the lowest hardware levels. We try to provide a
vendor-agnostic perspective and only occasionally call out platform-specific details.
For systems with persistent memory, failure atomicity guarantees that systems can
always recover to a consistent state following a power or system failure. Failure atomicity
for applications can be achieved using logging, flushing, and memory store barriers that
order such operations. Logging, either undo or redo, ensures atomicity when a failure
interrupts the last atomic operation from completion. Cache flushing ensures that
data held within volatile caches reach the persistence domain so it will not be lost if a
sudden failure occurs. Memory store barriers, such as an SFENCE operation on the x86
architecture, help prevent potential reordering in the memory hierarchy, as caches and
memory controllers may reorder memory operations. For example, a barrier ensures
that the undo log copy of the data gets persisted onto the persistent memory before the
actual data is modified in place. This guarantees that the last atomic operation can be
rolled back should a failure occur. However, it is nontrivial to add such failure atomicity
in user applications with low-level operations such as write logging, cache flushing, and
barriers. The Persistent Memory Development Kit (PMDK) was developed to isolate
developers from having to re-implement the hardware intricacies.
Failure atomicity should be a familiar concept, since most file systems implement
and perform journaling and flushing of their metadata to storage devices.
Chapter 2 persistent MeMory arChiteCture
• Data on persistent memory is instantly available, that is:
• Data is available as soon as power is applied to the system.
• Applications do not need to spend time warming up caches. They
can access the data immediately upon memory mapping it.
• Data residing on persistent memory has no DRAM footprint
unless the application copies data to DRAM for faster access.
• Data written to persistent memory modules is local to the system.
Applications are responsible for replicating data across systems.
Platform Support for Persistent Memory
Platform vendors such as Intel, AMD, ARM, and others will decide how persistent
memory should be implemented at the lowest hardware levels. We try to provide a
vendor-agnostic perspective and only occasionally call out platform-specific details.
For systems with persistent memory, failure atomicity guarantees that systems can
always recover to a consistent state following a power or system failure. Failure atomicity
for applications can be achieved using logging, flushing, and memory store barriers that
order such operations. Logging, either undo or redo, ensures atomicity when a failure
interrupts the last atomic operation from completion. Cache flushing ensures that
data held within volatile caches reach the persistence domain so it will not be lost if a
sudden failure occurs. Memory store barriers, such as an SFENCE operation on the x86
architecture, help prevent potential reordering in the memory hierarchy, as caches and
memory controllers may reorder memory operations. For example, a barrier ensures
that the undo log copy of the data gets persisted onto the persistent memory before the
actual data is modified in place. This guarantees that the last atomic operation can be
rolled back should a failure occur. However, it is nontrivial to add such failure atomicity
in user applications with low-level operations such as write logging, cache flushing, and
barriers. The Persistent Memory Development Kit (PMDK) was developed to isolate
developers from having to re-implement the hardware intricacies.
Failure atomicity should be a familiar concept, since most file systems implement
and perform journaling and flushing of their metadata to storage devices.
Chapter 2 persistent MeMory arChiteCture