335
examine the uncorrectable memory error, determine if the software can recover, and
perform recovery actions via an MCE handler. Typically, uncorrectable errors fall into
three categories:
• Uncorrectable errors that may have corrupted the state of the CPU
and require a system reset.
• Uncorrectable errors that can be recovered by software can be
handled during runtime.
• Uncorrectable errors that require no action.
Operating system vendors handle this uncorrectable error notification in different
ways, but some common elements exist for all of them.
Using Linux as an example, when the operating system receives a processor
interrupt for an uncorrectable error, it proceeds to offline the page of memory where
the uncorrectable error occurred and add the error to a list of areas containing known
uncorrectable errors. This list of known uncorrectable errors is called the bad block list.
Linux will also mark the page that contains the uncorrectable error to be cleared when
the page is recycled for use by another application.
The PMDK libraries automatically check the list of pages with uncorrectable errors in
the operating system and prevent an application from opening a persistent memory pool
if it contains errors. If a page of memory is in use by an application, Linux attempts to kill
it using the SIGBUS mechanism.
At this point, the application developer can decide what to do with this error
notification. The simplest way for you to handle uncorrectable errors is to let the
application die when it gets a SIGBUS so you do not need to write the complicated logic
of handling a SIGBUS at runtime. Instead, on restart, the application can use PMDK
to detect that the persistent memory pool contains errors and repair the data during
application initialization. For many applications, this repair can be as simple as reverting
to a backup error-free copy of the data.
Figure 17-1 shows a simplified sequence of how Linux can handle an uncorrectable
(but not fatal) error that was consumed by an application.
Chapter 17 reliability, availability, and ServiCeability (raS)
examine the uncorrectable memory error, determine if the software can recover, and
perform recovery actions via an MCE handler. Typically, uncorrectable errors fall into
three categories:
• Uncorrectable errors that may have corrupted the state of the CPU
and require a system reset.
• Uncorrectable errors that can be recovered by software can be
handled during runtime.
• Uncorrectable errors that require no action.
Operating system vendors handle this uncorrectable error notification in different
ways, but some common elements exist for all of them.
Using Linux as an example, when the operating system receives a processor
interrupt for an uncorrectable error, it proceeds to offline the page of memory where
the uncorrectable error occurred and add the error to a list of areas containing known
uncorrectable errors. This list of known uncorrectable errors is called the bad block list.
Linux will also mark the page that contains the uncorrectable error to be cleared when
the page is recycled for use by another application.
The PMDK libraries automatically check the list of pages with uncorrectable errors in
the operating system and prevent an application from opening a persistent memory pool
if it contains errors. If a page of memory is in use by an application, Linux attempts to kill
it using the SIGBUS mechanism.
At this point, the application developer can decide what to do with this error
notification. The simplest way for you to handle uncorrectable errors is to let the
application die when it gets a SIGBUS so you do not need to write the complicated logic
of handling a SIGBUS at runtime. Instead, on restart, the application can use PMDK
to detect that the persistent memory pool contains errors and repair the data during
application initialization. For many applications, this repair can be as simple as reverting
to a backup error-free copy of the data.
Figure 17-1 shows a simplified sequence of how Linux can handle an uncorrectable
(but not fatal) error that was consumed by an application.
Chapter 17 reliability, availability, and ServiCeability (raS)