29
System administrators may manually initiate an ARS. The intent is to identify bad
or potentially bad memory regions before the application does. If ARS identifies an
issue, the hardware can provide a status notification to the operating system and the
application that can be consumed and handled gracefully. If the bad address range
contains data, some method to reconstruct or restore the data needs to be implemented.
Chapter 17 describes ARS in more detail.
Developers are free to implement these features directly within the application code.
However, the libraries in the PMDK handle these complex conditions, and they will be
maintained for each product generation while maintaining stable APIs. This gives you
a future-proof option without needing to understand the intricacies of each CPU or
persistent memory product.
What’s Next?
Chapter 3 continues to provide foundational information from the perspective of the
kernel and user spaces. We describe how operating systems such as Linux and Windows
have adopted and implemented the SNIA non-volatile programming model that defines
recommended behavior between various user space and operating system kernel
components supporting persistent memory. Later chapters build on the foundations
provided in Chapters 1 through 3.
Summary
This chapter defines persistent memory and its characteristics, recaps how CPU caches
work, and describes why it is crucial for applications directly accessing persistent
memory to assume responsibility for flushing CPU caches. We focus primarily on
hardware implementations. User libraries, such as those delivered with the PMDK,
assume the responsibilities for architecture and hardware-specific operations and allow
developers to use simple APIs to implement them. Later chapters describe the PMDK
libraries in more detail and show how to use them in your application.
Chapter 2 persistent MeMory arChiteCture
Précédent

- 58/457

Suivant