339
Traditionally, the operating system executes ARS in one of two ways to obtain the
addresses of uncorrectable errors after a boot. Either a full scan is executed on all the
available persistent memory during system boot or after an unconsumed uncorrectable
memory error root-device notification is received. In both instances, the intent is to
discover these addresses before they are consumed by applications.
Operating systems will compare the list of uncorrectable errors returned by ARS to
their persistent list of uncorrectable errors. If new errors are detected, the list is updated.
This list is intended to be consumed by higher-level software, such as the PMDK libraries.
Clearing Uncorrectable Errors
Uncorrectable errors for persistent memory will survive power loss and may require special
handling to clear corrupted data from the memory address. When an uncorrectable error
is cleared, the data at the requested memory address is modified, and the error is cleared.
Because hardware cannot silently modify application data, clearing uncorrectable errors is
the software’s responsibility. Clearing uncorrectable errors is optional, and some operating
systems may choose to only offline memory pages that contain memory errors instead of
recycling memory pages that contain uncorrectable errors. In some operating systems,
privileged applications may have access to clear uncorrectable errors. Nevertheless, an
operating system is not required to provide this access.
The ACPI specification defines a Clear Uncorrectable Error DSM for operating
systems to instruct the platform to clear the uncorrectable errors. While persistent
memory programming is byte addressable, clearing uncorrectable errors is not. Different
vendor implementations of persistent memory may specify the alignment and size of the
memory unit that is to be cleared by a Clear Uncorrectable Error. Any internal platform
or operating system list of memory errors should also be updated upon successful
executing of the Clear Uncorrectable Error DSM command.
Device Health
System administrators may wish to act and mitigate any device health issues before they
begin to affect the availability of applications using persistent memory. To that end, operating
systems or management applications will want to discover an accurate picture of persistent
memory device health to correctly determine the reliability of the persistent memory.
The ACPI specification defines a few vendor-agnostic health discovery methods, but many
Chapter 17 reliability, availability, and ServiCeability (raS)
Traditionally, the operating system executes ARS in one of two ways to obtain the
addresses of uncorrectable errors after a boot. Either a full scan is executed on all the
available persistent memory during system boot or after an unconsumed uncorrectable
memory error root-device notification is received. In both instances, the intent is to
discover these addresses before they are consumed by applications.
Operating systems will compare the list of uncorrectable errors returned by ARS to
their persistent list of uncorrectable errors. If new errors are detected, the list is updated.
This list is intended to be consumed by higher-level software, such as the PMDK libraries.
Clearing Uncorrectable Errors
Uncorrectable errors for persistent memory will survive power loss and may require special
handling to clear corrupted data from the memory address. When an uncorrectable error
is cleared, the data at the requested memory address is modified, and the error is cleared.
Because hardware cannot silently modify application data, clearing uncorrectable errors is
the software’s responsibility. Clearing uncorrectable errors is optional, and some operating
systems may choose to only offline memory pages that contain memory errors instead of
recycling memory pages that contain uncorrectable errors. In some operating systems,
privileged applications may have access to clear uncorrectable errors. Nevertheless, an
operating system is not required to provide this access.
The ACPI specification defines a Clear Uncorrectable Error DSM for operating
systems to instruct the platform to clear the uncorrectable errors. While persistent
memory programming is byte addressable, clearing uncorrectable errors is not. Different
vendor implementations of persistent memory may specify the alignment and size of the
memory unit that is to be cleared by a Clear Uncorrectable Error. Any internal platform
or operating system list of memory errors should also be updated upon successful
executing of the Clear Uncorrectable Error DSM command.
Device Health
System administrators may wish to act and mitigate any device health issues before they
begin to affect the availability of applications using persistent memory. To that end, operating
systems or management applications will want to discover an accurate picture of persistent
memory device health to correctly determine the reliability of the persistent memory.
The ACPI specification defines a few vendor-agnostic health discovery methods, but many
Chapter 17 reliability, availability, and ServiCeability (raS)