Abstract: A method stores data that handles page faults in an appropriate memory device based on a standing memory policy. One or more processors receive user requested memory buffer attributes that describe memory buffer attributes needed for various processes. The processor(s) store the user requested memory buffer attributes in an operating system virtual memory representation that describes various types of memories used by the system, create a standing memory policy based on the user requested memory buffer attributes, and store data on an appropriate memory device based on the standing memory policy. The processor(s) receive a page fault, which is based on the data being called by a process but not being currently mapped by a memory management unit (MMU) into a virtual address space of the process. The processor(s) then retrieve and return the data stored on the appropriate memory device in order to address the page fault.

Abstract: A technique for handling uncorrected memory errors (UEs) inside a kernel text section, the kernel text section being stored in a memory that is operably coupled to a CPU executing kernel program instructions. In an embodiment, a UE is detected that affects the kernel text section. The current instruction affected by the UE is identified. The UE-affected instruction is recovered by loading a copy thereof into the memory from a kernel image maintained in persistent storage. The UE-affected instruction is emulated using the copy of the UE-affected instruction. The instruction pointer of the CPU is then incremented to point to a next instruction in the memory that would normally be executed by the UE-affected instruction had there been no UE.

Abstract: Predicting physical memory attributes by compiler analysis of code blocks includes receiving source code including at least one code block, and identifying a buffer associated with the at least one code block. Buffer access characteristics associated with the buffer are determined from the at least one code block. The buffer access characteristics are mapped to physical memory attributes associated with one or more physical memories of a computing system. Executable program code including a system call associated with memory allocation is generated based upon the physical memory attribute values.

Abstract: Predicting physical memory attributes by compiler analysis of code blocks includes receiving source code including at least one code block, and identifying a buffer associated with the at least one code block. Buffer access characteristics associated with the buffer are determined from the at least one code block. The buffer access characteristics are mapped to physical memory attributes associated with one or more physical memories of a computing system. Executable program code including a system call associated with memory allocation is generated based upon the physical memory attribute values.

Abstract: A technique for handling uncorrected memory errors (UEs) inside a kernel text section, the kernel text section being stored in a memory that is operably coupled to a CPU executing kernel program instructions. In an embodiment, a UE is detected that affects the kernel text section. The current instruction affected by the UE is identified. The UE-affected instruction is recovered by loading a copy thereof into the memory from a kernel image maintained in persistent storage. The UE-affected instruction is emulated using the copy of the UE-affected instruction. The instruction pointer of the CPU is then incremented to point to a next instruction in the memory that would normally be executed by the UE-affected instruction had there been no UE.

Abstract: A method stores data that handles page faults in an appropriate memory device based on a standing memory policy. One or more processors receive user requested memory buffer attributes that describe memory buffer attributes needed for various processes. The processor(s) store the user requested memory buffer attributes in an operating system virtual memory representation that describes various types of memories used by the system, create a standing memory policy based on the user requested memory buffer attributes, and store data on an appropriate memory device based on the standing memory policy. The processor(s) receive a page fault, which is based on the data being called by a process but not being currently mapped by a memory management unit (MMU) into a virtual address space of the process. The processor(s) then retrieve and return the data stored on the appropriate memory device in order to address the page fault.

Abstract: An application can specify reliability values via a communication path between the application and the registers. Application reliability could increase if the application itself could specify the timeout and retry values. For instance, some errors might be prevented if the timeout value is lengthened by a short amount. A longer timeout value would result in slower performance because the memory component could not be accessed during the timeout period. However, resolving errors in memory devices would prevent unrecoverable error indicators from being returned to the application, which would in turn limit application and system crashes. Creating a communication path between the application and the hardware registers would allow the application to modify the reliability of memory operations.

Abstract: In some example embodiments, a method includes performing a memory scrub of a memory across a scrub cycle of multiple scrub cycles. The method includes identifying correctable errors of symbols in the memory that are a result of accesses from a section of the memory in response to the memory scrub. The method also includes performing an analysis across the multiple scrub cycles, wherein the performing of the analysis comprises determining whether at least two symbols across the multiple scrub cycles have at least one correctable error. The method includes responsive to determining that at least two symbols across the multiple scrub cycles have at least one correctable error, executing at least one repair of the memory that includes the section of memory.

Abstract: An apparatus includes a processor, a memory, and an error module operable on the processor. The error module is configured to perform a memory scrub of the memory across a scrub cycle of multiple scrub cycles. The error module is configured to identify correctable errors of symbols in the memory that are a result of accesses from a section of the memory in response to the memory scrub. The error module is configured to perform an analysis across the multiple scrub cycles, wherein the analysis comprises a determination whether at least two symbols across the multiple scrub cycles have at least one correctable error. The error module is configured to responsive to a determination that at least two symbols across the multiple scrub cycles have at least one correctable error, execute at least one repair of the memory that includes the section of memory.

Abstract: An application can specify reliability values via a communication path between the application and the registers. Application reliability could increase if the application itself could specify the timeout and retry values. For instance, some errors might be prevented if the timeout value is lengthened by a short amount. A longer timeout value would result in slower performance because the memory component could not be accessed during the timeout period. However, resolving errors in memory devices would prevent unrecoverable error indicators from being returned to the application, which would in turn limit application and system crashes. Creating a communication path between the application and the hardware registers would allow the application to modify the reliability of memory operations.

Abstract: Mechanisms are provided in which firmware verifies he entire system's memory scrub coverage through some additional memory controller (MC) registers/attentions and builds up a processor runtime diagnostic (PRD) scrub coverage table during every scrub cycle. Firmware may go through the scrub coverage table rank-by-rank on a periodic basis to determine whether any ranks had not been covered by hardware scrubbing. Firmware may initiate a targeted scrub and diagnostic for all of the ranks that did not have adequate scrub coverage. If for some reason the system still has some memory ranks that have not been covered by the initial hardware scrub and the targeted scrub, then the firmware may perform some course of action for fault isolation.

Abstract: In some example embodiments, a method includes performing a memory scrub of a memory across a scrub cycle of multiple scrub cycles. The method includes identifying correctable errors of symbols in the memory that are a result of accesses from a section of the memory in response to the memory scrub. The method also includes performing an analysis across the multiple scrub cycles, wherein the performing of the analysis comprises determining whether at least two symbols across the multiple scrub cycles have at least one correctable error. The method includes responsive to determining that at least two symbols across the multiple scrub cycles have at least one correctable error, executing at least one repair of the memory that includes the section of memory.

Abstract: An apparatus includes a processor, a memory, and an error module operable on the processor. The error module is configured to perform a memory scrub of the memory across a scrub cycle of multiple scrub cycles. The error module is configured to identify correctable errors of symbols in the memory that are a result of accesses from a section of the memory in response to the memory scrub. The error module is configured to perform an analysis across the multiple scrub cycles, wherein the analysis comprises a determination whether at least two symbols across the multiple scrub cycles have at least one correctable error. The error module is configured to responsive to a determination that at least two symbols across the multiple scrub cycles have at least one correctable error, execute at least one repair of the memory that includes the section of memory.

Abstract: Mechanisms are provided in which firmware verifies he entire system's memory scrub coverage through some additional memory controller (MC) registers/attentions and builds up a processor runtime diagnostic (PRD) scrub coverage table during every scrub cycle. Firmware may go through the scrub coverage table rank-by-rank on a periodic basis to determine whether any ranks had not been covered by hardware scrubbing. Firmware may initiate a targeted scrub and diagnostic for all of the ranks that did not have adequate scrub coverage. If for some reason the system still has some memory ranks that have not been covered by the initial hardware scrub and the targeted scrub, then the firmware may perform some course of action for fault isolation.

Abstract: An application can specify reliability values via a communication path between the application and the registers. Application reliability could increase if the application itself could specify the timeout and retry values. For instance, some errors might be prevented if the timeout value is lengthened by a short amount. A longer timeout value would result in slower performance because the memory component could not be accessed during the timeout period. However, resolving errors in memory devices would prevent unrecoverable error indicators from being returned to the application, which would in turn limit application and system crashes.

Abstract: An application can specify reliability values via a communication path between the application and the registers. Application reliability could increase if the application itself could specify the timeout and retry values. For instance, some errors might be prevented if the timeout value is lengthened by a short amount. A longer timeout value would result in slower performance because the memory component could not be accessed during the timeout period. However, resolving errors in memory devices would prevent unrecoverable error indicators from being returned to the application, which would in turn limit application and system crashes.

Abstract: Methods, systems and computer program products for architecting fault tolerant applications. Embodiments of the invention include a method for executing an application in a computer system, the method including monitoring a behavior of the computer system, the computer system having a subsystem in an operating system of the computer system, in response to encountering a problem in the computer system, performing switching the application from a normal mode of operation to a critical mode of operation, executing the application in the critical mode of operation, determining if the computer system has returned to the normal mode of operation, in response to the computer system returning to the normal mode of operation switching the application to execute in the normal mode and executing the application in the normal mode of operation.

Abstract: Methods, systems and computer program products for architecting fault tolerant applications. Embodiments of the invention include a method for executing an application in a computer system, the method including monitoring a behavior of the computer system, the computer system having a subsystem in an operating system of the computer system, in response to encountering a problem in the computer system, performing switching the application from a normal mode of operation to a critical mode of operation, executing the application in the critical mode of operation, determining if the computer system has returned to the normal mode of operation, in response to the computer system returning to the normal mode of operation switching the application to execute in the normal mode and executing the application in the normal mode of operation.