CN117093390A - System for processing faulty page, method for processing faulty page, and host device - Google Patents

Abstract

A system for processing a failed page, a method of processing a failed page, and a host device are provided. The system comprises: a host processor; a host memory connected to the host processor through a first memory interface; and an expandable memory pool connected to the host processor through a second memory interface, the second memory interface being different from the first memory interface, the host memory including instructions that, when executed by the host processor, cause the host processor to: detecting an error in a target page of a first memory device of the scalable memory pool; generating an interrupt in response to detecting the error; storing fault page information corresponding to a target page of the first memory device in a fault page log; and changing the state of the target page of the first memory device from the first state to the second state according to the fault page log.

Description

System for handling failed pages, method of handling failed pages, and host device

This application claims priority and the benefit of U.S. Provisional Application No. 63/343410 entitled "UE (Uncorrectable Error) Processing of CXL Memory", filed on May 18, 2022, and all of said U.S. Provisional Application The content is incorporated herein by reference.

Technical field

One or more embodiments of the present disclosure relate to scalable memory, and more particularly, to error handling for scalable memory.

Background technique

A machine check exception (MCE) is a type of hardware error that occurs when a system's central processing unit (CPU) detects errors in memory, I/O devices, the system bus, the processor itself, etc. Correctable memory errors are typically single-bit errors that are correctable by the system and typically do not result in system failure or data corruption. On the other hand, uncorrectable memory errors are usually multiple bits that indicate some critical or fatal event in the memory itself that can usually be due to some fault in the memory module (e.g., memory chip) that is not correctable by software/firmware ( multi-bit) error.

The above information disclosed in this Background section is provided to enhance understanding of the context of the disclosure and therefore it may contain information that does not constitute prior art.

Contents of the invention

One or more embodiments of the present disclosure are directed to error handling for scalable memory, and more particularly, to generating fault page information that can be persistently stored and used to automatically take fault pages of an scalable memory device offline.

One or more embodiments of the present disclosure are directed to sharing fault page information among multiple host devices to automatically take fault pages of an expandable memory device offline.

According to one or more embodiments of the present disclosure, a system for handling fault pages includes: a host processor; a host memory connected to the host processor through a first memory interface; and an expandable memory pool through a second memory An interface is connected to the host processor, the second memory interface is different from the first memory interface, and the host memory includes instructions that when executed by the host processor cause the host processor to: detect a target of the first memory device of the scalable memory pool an error in the page; in response to detecting the error, generating an interrupt; storing fault page information corresponding to the target page of the first memory device in the fault page log; and based on the fault page log, converting the target page of the first memory device to The status of the page changes from the first status to the second status.

In one embodiment, the second memory interface may include a Peripheral Component Interconnect Express (PCIe) interface and a Compute Express Link (CXL) interconnect.

In one embodiment, the first memory interface may include a dual in-line memory module (DIMM).

In one embodiment, a scalable memory pool may include at least two different types of Compute Express Link (CXL) memory devices.

In one embodiment, the instructions further cause the host processor to: perform a restart; read a fault page log to identify one or more fault pages of the scalable memory pool; and based on the fault page log, set the one or The second state of multiple failed pages.

In one embodiment, the instructions further cause the host processor to: receive a log request for a fault page log from a guest host processor configured to access the scalable memory pool; and in response to the log request, Send the fault page log to the guest host processor. The guest host processor may be configured to set a second state of one or more pages of the scalable memory pool based on the failed page log.

In one embodiment, the instructions further cause the host processor to: receive an update from a first guest host processor that detects an error in a second memory device in the scalable memory pool; based on the The updating identifies a faulty page of the second memory device; updates a faulty page log; and sets a second state of the faulty page of the second memory device based on the updated faulty page log.

In one embodiment, the instructions may further cause the host processor to: broadcast the updated fault page log to a second guest host processor configured to access the scalable memory pool.

In one embodiment, the error may be a multi-bit error in a target page of a first memory device of the scalable memory pool, and the failed page information may include physical device information of the target page of the first memory device.

According to one or more embodiments of the present disclosure, a method of handling a faulty page includes: detecting, by a kernel of a first host device, an error in a target page of a first memory device of an expandable memory pool; in response to detecting the error, by the kernel generating an interrupt; by a device driver corresponding to the first memory device storing fault page information corresponding to the target page of the first memory device in a fault page log; and by a fault page log (FPL) daemon Changing a state of a target page of the first memory device from a first state to a second state according to the fault page log.

In one embodiment, the first memory device of the scalable memory pool may be connected to the first host device via a Peripheral Component Interconnect Express (PCIe) interface and a Compute Express Link (CXL) interconnect.

In one embodiment, a scalable memory pool may include at least two different types of Compute Express Link (CXL) memory devices.

In one embodiment, the method may further include: performing a restart by the kernel; reading a fault page log by the FPL daemon to identify one or more fault pages of the scalable memory pool; and, by the FPL daemon, based on The fault page log sets a second state of the one or more fault pages.

In one embodiment, the method may further include receiving, by the FPL daemon of the first host device, a log request for the fault page log from the FPL daemon of the second host device, the second host device being configured to access the scalable a memory pool; and in response to the log request, sending the fault page log to the second host device by the FPL daemon of the first host device. The FPL daemon of the second host device may be configured to set a second state of one or more failed pages of the scalable memory pool based on the failed page log.

In one embodiment, the method may further include: in response to the second host device detecting an error in the second memory device in the scalable memory pool, causing the FPL daemon of the first host device to retrieve the error from the second host device. The update is received by the FPL daemon; the fault page of the second memory device is identified by the FPL daemon of the first host device based on the update; the fault page log is updated by the FPL daemon of the first host device; and the fault page log is updated by the FPL daemon of the first host device The daemon sets a second state of the fault page of the second memory device based on the updated fault page log.

In one embodiment, the method may further include broadcasting, by the FPL daemon of the first host device, the updated fault page log to a third host device, the third host device being configured to access the scalable memory pool.

In one embodiment, the error may be a multi-bit error in a target page of a first memory device of the scalable memory pool, and the failed page information may include physical device information of the target page of the first memory device.

According to one or more embodiments of the present disclosure, a host device includes: a root complex connected to an extensible memory pool through a memory interface and configured to parse packets received from a memory device of the extensible memory pool; a kernel, configured to detect an error bit corresponding to a faulty page of the first memory device from the parsed packet, and to generate an interrupt in response to detecting the error bit; a driver of the first memory device configured to respond to the interrupt. Fault page information corresponding to the fault page of the first memory device is stored in the fault page log; and a fault page log (FPL) daemon is configured to change the state of the fault page from the first state to the second state based on the fault page log. state.

In one embodiment, a scalable memory pool may include at least two different types of Compute Express Link (CXL) memory devices.

In one embodiment, in response to the restart, the FPL daemon may be configured to: read the fault page log to identify one or more fault pages of the scalable memory pool, and set the one or more faults according to the fault page log The second state of the page.

Description of the drawings

The above and other aspects and features of the present disclosure will be more clearly understood from the following detailed description of illustrative, non-limiting embodiments with reference to the accompanying drawings.

Figure 1 is a schematic block diagram of a scalable memory system in accordance with one or more embodiments of the present disclosure.

2 is a schematic block diagram of a host device of an expandable memory system in accordance with one or more embodiments of the present disclosure.

3 is a flowchart of a method of generating a fault page log for an expandable memory device in accordance with one or more embodiments of the present disclosure.

4 is a flowchart of a method of taking fault pages of an expandable memory device offline after a system restart.

Figure 5 is a schematic block diagram of a scalable memory system in accordance with one or more embodiments of the present disclosure.

6 is a flowchart of a method of sharing fault page information of an expandable memory device according to one or more embodiments of the present disclosure.

Figure 7 is a schematic block diagram of a scalable memory system in accordance with one or more embodiments of the present disclosure.

8 is a flowchart of a method of updating fault page information of an expandable memory device according to one or more embodiments of the present disclosure.

Detailed ways

In the following, embodiments will be described in more detail with reference to the accompanying drawings, wherein like reference numerals refer to like elements throughout. This disclosure may, however, be embodied in various different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey the aspects and features of the disclosure to those skilled in the art. Accordingly, processes, elements, and techniques may not be described that are not necessary for one of ordinary skill in the art to fully understand aspects and features of the present disclosure. Unless otherwise stated, the same reference numbers refer to the same elements throughout the drawings and written description, and therefore, their redundant description may not be repeated.

In general, uncorrectable errors (eg, multi-bit errors) in expandable memory may not be used for pages critical to the operation of the system (such as kernel pages, execution pages, non-relocatable pages, etc.) Has less impact on system stability. Therefore, when an uncorrectable error occurs in a page of scalable memory, the likelihood of a system crash may be lower, and thus, the page may simply be taken offline (e.g., the state of the page may be changed from the first state (e.g., online or available state) is changed to a second state (e.g., offline or unavailable state) such that any applications and/or processes accessing the page may be forced to close (e.g., may be terminated). However, Since the central processing unit (CPU) typically does not maintain information for offline pages, memory mapping to faulty pages may continue to be repeated (especially after a system restart), and therefore, the user experience may be degraded.

Typically, system main memory (e.g., host memory) may be used for pages critical to the operation of the system (such as kernel pages, application execution pages, non-relocatable pages, etc.), as well as pages used for processing data (such as text pages, file pages, etc.) page, anonymous page, removable page, etc.). Therefore, in order to ensure system stability and prevent system crashes from occurring, when an uncorrectable error occurs in a page of the system's main memory, the system may be shut down so that a user (eg, an administrator) can perform operations on the memory where the uncorrectable error occurred. Devices (eg, dynamic random access memory (DRAM) devices or chips) are replaced. Therefore, an error log, such as a Machine Check Exception (MCE) log, may simply contain the error message and some basic information to enable the user to replace a system main memory device where an uncorrectable error occurred.

On the other hand, expandable memory may not typically be used for critical pages, but may be used only for processing data. Therefore, unlike the situation with system main memory, when an uncorrectable error occurs in a page of expandable memory, the page can be taken offline (eg, the page can become unavailable), and access to the page of expandable memory Any applications and/or processes may be forced to close (eg, may be terminated), while other pages of the expandable memory may continue to be used. Therefore, unlike system main memory, which can be replaced when an uncorrectable error occurs therein, the usable life of an expandable memory device can be extended or maximized by taking faulty pages offline, and therefore, costs can be reduced.

Typically, however, the system processor (eg, the host processor) may not maintain offline pages of scalable memory, and therefore, when the system is restarted, the memory mapping to the faulty page may be repeated. Additionally, because error logs typically do not include physical device information (eg, device serial number, device type, and device physical address) for faulty pages of expandable memory, offline pages may not be shared between different host processors. For example, because different systems may have different system mappings, the error logs of one host processor may not be related to another host processor. Therefore, even if the faulty page is taken offline by another host processor, the different host processors may continue the memory mapping of the faulty page to the expandable memory.

According to one or more embodiments of the present disclosure, fault page information for fault pages in the expandable memory device may be generated and persistently stored in a fault page log (FPL) even after a system restart, so that the FPL is available Any faulty pages of the expandable memory device are automatically taken offline before memory mapping to the faulty page can occur. Therefore, user experience can be improved and costs can be reduced.

According to one or more embodiments of the present disclosure, the FPL may include at least physical device information (e.g., device serial number, device type, device physical address, etc.). Therefore, even after a system reboot, hardware change, etc. where the host physical address may be changed, FPL can be used to automatically take the faulty page offline before any memory mapping to the faulty page can occur.

For example, the host physical address may be changed when expandable memory is inserted into a different slot of the host device, or when an expandable memory expansion card is inserted into a slot of a different host device. In this case, when such a hardware change is made, the FPL including at least the physical device information of the expandable memory can implement remapping from the device physical address to the host physical address. In some embodiments, the host physical address may be reused to take faulted pages offline when no hardware changes are made.

According to one or more embodiments of the present disclosure, because the FPL may include at least physical device information of the fault page, the FPL may be shared among multiple host devices (eg, host processors) such that among the multiple host processors Each of them can take the fault page offline in their own system map, and therefore, any memory mapping to the fault page can be avoided. Therefore, system reliability can be improved, and user experience can be improved.

The above and/or other aspects and features of the present disclosure will be described in more detail below with reference to the accompanying drawings.

Figure 1 is a schematic block diagram of a scalable memory system in accordance with one or more embodiments of the present disclosure.

Referring to FIG. 1 , host device 102 may include a host operating system (OS)/kernel 104 , a host processor 106 , host memory 108 , and storage 110 . Host operating system/kernel 104 may include system software for providing interfaces between hardware and users and between software applications and hardware. For example, the host operating system/kernel 104 may be configured for resource allocation, memory management, CPU management, file management, execution of processes, etc. of the host device 102 . For example, in some embodiments, the host operating system/kernel 104 may include a Linux operating system/kernel, but the disclosure is not limited thereto and the host operating system/kernel 104 may include any suitable operating system known to those skilled in the art. /kernel (such as Windows OS, Apple OS (e.g., macOS), Chrome OS, etc.).

Host processor 106 may be processing circuitry of host device 102 (eg, such as a general purpose processor or central processing unit (CPU) core). The host processor 106 may be connected to other components via an address bus, a control bus, a data bus, and the like. Host processor 106 can execute instructions stored in host memory 108 to perform the various operations described herein. For example, host processor 106 execution may be copied from a persistent storage device (e.g., storage 110 , read-only memory (ROM), etc.) as needed or desired (e.g., at startup, execution time, interrupt routines, etc.) One or more system processes and background processes (described in greater detail below) to host memory 108 .

Host memory 108 may be considered the high-performance main memory (eg, primary memory) of host device 102 . For example, in some embodiments, host memory 108 may include (or may be) volatile memory (eg, such as dynamic random access memory) that may be connected directly to a memory slot of a motherboard of host device 102 via first memory interface 112 . memory (DRAM)). In this case, the first memory interface 112 (eg, the connector and its protocol) may include (or may be compliant with) a dual in-line memory module (DIMM) to facilitate (eg, via the host OS/kernel 104 ) Communication between host memory 108 and host processor 106 is such that host memory 108 may be a DIMM memory connected to a DIMM slot of host device 102 . However, the present disclosure is not so limited, and host memory 108 may include (or may be) a replacement for any suitable high-performance main memory (eg, primary memory) for host device 102 as would be known to those skilled in the art. . For example, in other embodiments, the host memory 108 may be a relatively high performance non-volatile memory (such as NAND flash memory, phase change memory (PCM), resistive RAM, spin transfer torque RAM (STTRAM), PCM-based technology, memristor technology, and/or resistive random access memory (ReRAM)), and may include, for example, chalcogenides and the like.

Storage device 110 may be thought of as secondary storage (eg, secondary storage) that may persistently store data accessible by host device 102 . In this context, storage device 110 may include (or may be) relatively slow memory when compared to the high performance main memory of host memory 108 . For example, in some embodiments, storage device 110 may be a solid state drive (SSD). However, the present disclosure is not limited thereto, and in other embodiments, storage device 110 may include (or may be) any suitable storage device (eg, such as a magnetic storage device (eg, a hard disk drive (HDD), etc.), optical storage device devices (e.g., Blu-ray disk drives, compact disk (CD) drives, digital versatile disk (DVD) drives, etc.), other types of flash memory devices (e.g., USB flash drives, etc.), etc.). In various embodiments, storage device 110 may comply with large form factor standards (eg, 3.5-inch hard drive form factor), small form factor standards (eg, 2.5-inch hard drive form factor), M.2 form factor, E1. S shape factor etc. In other embodiments, memory device 110 may conform to any suitable or desired derivative of these form factors.

Storage device 110 may be connected to host processor 106 via a storage interface. The storage interface may facilitate communication between the host processor 106 and the storage device 110 (eg, via the host OS/kernel 104 ) (eg, using connectors and protocols). In some embodiments, a storage interface may facilitate the exchange of storage requests and responses between host processor 106 and storage device 110 . In some embodiments, the storage interface may facilitate the transfer of data by storage device 110 to and from host memory 108 of host device 102 . For example, in various embodiments, storage interfaces (e.g., connectors and their protocols) may include (or may be compliant with) Small Computer System Interface (SCSI), Non-Volatile Memory Express (NVMe), Peripheral Component Interconnect Express (PCIe), Remote Direct Memory Access (RDMA) over Ethernet, Serial Advanced Technology Attachment (SATA), Fiber Channel, Serial Attached SCSI (SAS), NVMe over the network (NVMe-oF), and more. In other embodiments, storage interfaces (eg, connectors and their protocols) may include (or may be compliant with) various general-purpose interfaces (eg, such as Ethernet, Universal Serial Bus (USB), etc.).

Still referring to FIG. 1 , host device 102 is connected to scalable memory pool 114 via a second memory interface 116 that is different from first memory interface 112 . Scalable memory pool 114 may include one or more scalable memory devices 118a, 118b, and 118c (collectively 118) (eg, such as one or more Compute Express Link (CXL) memory devices 118a (CXL_Memory 1), 118b ( CXL_Memory 2) and 118c (CXL_Memory 3)). In some embodiments, scalable memory pool 114 may be a disaggregated CXL memory pool including multiple different types of CXL memory devices 118a, 118b, and 118c, which may typically include volatile memory (such as, e.g. DDR3, DDR4, DDR5, low power, high power, low profile, PMEM, HBM, SSD with DRAM, etc.). However, the present disclosure is not so limited, and similar to the example described above with respect to host memory 108 , scalable memory pool 114 may include (or may be) any suitable memory for host device 102 as will be known to those skilled in the art. High performance scalable memory. For example, scalable memory pool 114 may include at least two different types of CXL memory devices.

In some embodiments, the second memory interface 116 may include a Peripheral Component Interconnect Express (PCIe) interface and a CXL interconnect. For example, the second memory interface 116 (eg, the connector and its protocol) may include (eg, may be compliant with) a CXL interconnect built on Peripheral Component Interconnect Express (PCIe) to (eg, via the host OS/kernel 104 ) facilitates communication between the host processor 106 and the memory devices 118a, 118b, and 118c of the scalable memory pool 114. In this case, each of memory devices 118a, 118b, and 118c may be connected to a PCIe slot of host device 102 as a PCIe device. In other embodiments, the second memory interface 116 (eg, connectors and their protocols) may include (or may be compliant with) various general-purpose interfaces (eg, such as Ethernet, Universal Serial Bus (USB), etc.). Although FIG. 1 illustrates one host device 102 connected to scalable memory pool 114, the present disclosure is not so limited and multiple host devices 102 may be connected to scalable memory pool 114 (eg, see FIGS. 5 and 7).

As described above, host memory 108 and scalable memory pool 114 may both be used as high-performance main memory (eg, primary memory) for host device 102 such that they both may be used for data processing (eg, for temporary storage of data to be processed). The host processor 106 processes data (eg, such as text pages, anonymous pages, file pages, removable pages, etc. (eg, see FIG. 2 )). However, while host memory 108 may also be used for critical pages (such as OS kernel pages, application execution pages, non-relocatable pages, etc.), scalable memory pool 114 may not be used for such critical pages. Thus, when an uncorrectable error occurs in a page of host memory 108 , host memory 108 may be replaced to prevent or substantially prevent a system crash, unlike host memory 108 when an uncorrectable error occurs in a page of scalable memory pool 114 When an uncorrectable error occurs in a page of device 118, the page may simply be taken offline (e.g., the status of the page may be changed from a first state (e.g., online state or available state) to a second state (e.g., offline state or unavailable state)), so that any process and/or application accessing the page can be terminated (e.g., forced shut down). In other words, rather than being replaced like host memory 108 , when an uncorrectable error occurs in a page of scalable memory pool 114 , the page can be hard-offlined as one of ordinary skill in the art will understand, such that the failed page No longer available for memory mapping. Accordingly, the usable lifetime of the scalable memory devices 118 of the scalable memory pool 114 may be increased or maximized, and therefore, costs may be reduced. As used herein, an uncorrectable error may mean a multi-bit error (e.g., a 2-bit error) on the same cache line that cannot be corrected by system software/firmware (e.g., may be uncorrectable), while a correctable An error can represent a single bit error and is usually correctable by the system.

It should be noted that correctable errors in pages of scalable memory pool 114 may be handled in substantially the same or substantially the same manner as correctable errors that may occur in pages of host memory 108 are handled. For example, when a correctable error occurs, the data of the page with the correctable error can be migrated to another page, and the page with the correctable error can be soft-offlined as will be understood by one of ordinary skill in the art. , so that any application or process that accesses the faulty page can be remapped to the migrated page. However, in some embodiments, the embodiments described in more detail below may also be extended to soft offline pages (eg, by persistently storing fault page information for soft offline pages in a fault page log). In this case, the fault page log may be used (eg, at system 100 startup (or after a reboot)) to take pages offline as needed or desired. For convenience, embodiments described in greater detail below may be described in the context of hard offline pages in response to uncorrectable errors (eg, two-bit errors on the same cache line), but the disclosure is not limited thereto. And at least some of the embodiments described herein may also be applicable to soft offline pages in response to correctable errors.

2 is a schematic block diagram of a host device of an expandable memory system in accordance with one or more embodiments of the present disclosure.

Referring to FIG. 2 , host device 102 is connected to expandable memory device 118 of expandable memory pool 114 via second memory interface 116 . For example, in some embodiments, expandable memory device 118 may be connected (eg, via second memory interface 116 ) to a port (eg, a PCIe port) of root complex 202 of host device 102 such that expandable memory device 118 may Considered a PCIe device. In this case, root complex 202 may connect processor 206 (eg, host processor 106 in FIG. 1 ) to expandable memory device 118 to generate transaction requests to expandable memory device 118 on behalf of processor 206 . Root complex 202 may be implemented as an integrated circuit, or the functionality of root complex 202 may be implemented as part of processor 206 (eg, as instructions stored in memory 208 and executed by processor 206).

Briefly, when an uncorrectable error occurs in a target page of expandable memory device 118, the target register of the expandable memory device may generate an error bit in the target packet (eg, in a translation layer packet) (eg, a poison bit), and the target packet is provided to the root complex 202. Root complex 202 parses the target packet and sends the parsed target packet, including error bits, to processor 206 (eg, host processor 106). Processor 206 generates an interrupt based on the error bit and persistently stores fault page information including at least physical device information of the target page (eg, device serial number, device type, device physical address, etc.) in fault page log FPL 222 . Processor 206 may take the target page offline in accordance with FPL 222 and may terminate any process or application accessing the target page. FPL 222 may be persistently stored in persistent storage 218 (eg, storage 110 in FIG. 1 , etc.) such that fault page information is maintained in FPL 222 even after a system restart. Therefore, in some embodiments, when the system is restarted, FPL 222 may be read for each of scalable memory devices 118 in scalable memory pool 114 such that a faulted page identified in FPL 222 may be read at any time. Memory mapping to faulted pages is automatically taken offline before they occur, and therefore, error logs (eg, MCE logs) can be reduced and user experience can be improved.

In further detail, host device 102 may include root complex 202, processing circuitry 204, and persistent storage 218 (eg, storage 110, etc.). Root complex 202 may connect processing circuitry 204 (eg, via a local bus, etc.) to expandable memory device 118 via second memory interface 116 . For example, as discussed above, the second memory interface 116 (eg, the connector and its protocol) may include (eg, may be compliant with) a CXL interconnect built on Peripheral Component Interconnect Express (PCIe) such that the memory device can be expanded 118 may be a PCIe device connected to a PCIe port of root complex 202 . Although FIG. 2 shows root complex 202 as separate from processing circuit 204, the present disclosure is not so limited, and in some embodiments, root complex 202 may be implemented as part of processing circuit 204 (e.g., as an integrated circuit or as part of processor 206).

Processing circuitry 204 includes one or more processors 206 (eg, which may include host processor 106 in FIG. 1 ) and memory 208 (eg, host memory 108, ROM, etc.). Processing circuitry 204 may be connected to (or may include) root complex 202 such that processing circuitry 204 and its various components may send and receive data via root complex 202 and expandable memory device 118 . Processor 206 may be a general purpose processor such as a central processing unit (eg, CPU), an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a set of component, or other suitable electronic processing component capable of executing instructions (e.g., via firmware and/or software). Processing circuitry 204 and processor 206 may be housed in a single geographic location or device, or may be distributed over various geographic locations or devices.

Memory 208 (e.g., one or more memory devices and/or memory cells) may include tangible, non-transitory, volatile memory or non-volatile memory such as RAM (e.g., DRAM), ROM, NVRAM, or flash memory ). Memory 208 may be communicatively connected to processor 206 via processing circuitry 204 and includes data and/or data for facilitating at least some of the various processes described herein (eg, by processing circuitry 204 and/or processor 206 ). or computer code. For example, memory 208 may include database components, object code components, script components, and/or any other type of information or data structure used to support the various activities and information or data structures described in this application. Memory 208 stores instructions or programming logic that, when executed by processor 206, control various operations of host device 102 described herein.

As shown in FIG. 2, memory 208 may include data that may be copied from a persistent storage device (eg, storage 110, ROM, etc.) to The various instructions in memory 208 correspond to the OS kernel 210, Machine Check Exception (MCE) log daemon 212, device driver 214, and Fault Page Log (FPL) daemon 216. For example, OS kernel 210 may include various system software to provide interfaces between software applications and hardware (eg, CPU, memory, storage devices, etc.), and device drivers 214 may include expandable memory for expandable memory pool 114 A device driver for each of devices 118 . MCE log daemon 212 and FPL daemon 216 may include (or may be) various background processes that may be invoked, for example, in response to an interrupt or after a restart.

OS kernel 210 may detect machine check exceptions (MCEs) from various hardware (such as from host processor 106, host memory 108, storage device 110, expandable memory device 118, etc.) and may detect them via an error log or system console. Provide some error message to users (for example, system administrators). In the event that the MCE corresponds to an uncorrectable error detected from a page in host memory 108, if the page is critical to the system, the OS kernel 210 may shut down the system to prevent a system crash, and in this case, typically Nothing is recorded. In some embodiments, the MCE log daemon 212, which may be a third-party user application, may also be included to provide some additional information about the detected MCE (e.g., host physical address (if supported), memory mapping information, etc.) , and additional information may be stored, for example, in MCE log 220. However, MCE log 220 is primarily for host memory 108 , and since expandable memory device 118 may simply be considered a memory expansion attached to a PCIe slot of host device 102 , MCE log 220 may not be logged with expandable memory. Complete information about uncorrectable errors in the device 118 fault page. In other words, MCE log 220 may not contain fault page information (eg, physical device information) of the expandable memory. Therefore, MCE log 220 may simply store information identifying the memory device of host memory 108 that needs to be replaced, which information may include the physical address of the faulty page of host memory 108 (if supported), but due to the attached CXL/PCIe/ All expandable memory devices 118 on the network may be considered memory extensions, so the MCE log 220 may not be sufficient to store fault page information for uncorrectable errors in the expandable memory devices 118 of the expandable memory pool 114 .

In accordance with one or more embodiments of the present disclosure, when an MCE corresponds to an uncorrectable error detected from a page in expandable memory device 118, the failed page information (e.g., physical device information (such as device serial number, device Type, device physical address, etc.) may be persistently stored in the FPL 222 and may be used to automatically take faulty pages offline in the expandable memory device 118 even in the event of hardware configuration changes and/or server changes. For example, if expandable memory device 118 is moved from slot 1 to slot 2, the hardware device management (HDM) scope may be changed, and such changes may not be tracked by expandable memory device 118 . On the other hand, because FPL 222 persistently stores fault page information, such information can be used to take fault pages in expandable memory device 118 offline even in the event of such changes.

In more detail, when OS kernel 210 detects an MCE corresponding to a target page of expandable memory device 118 (eg, based on parsed error bits from root complex 202 ), OS kernel 210 may generate an access to expandable memory device. The application or process of the target page 118 is interrupted, and the device driver 214 of the expandable memory device 118 may be called to handle the interrupt. Device driver 214 of expandable memory device 118 may include an advanced error reporting (AER) handler to handle MCEs detected in expandable memory device 118 in response to interrupts. For example, if the MCE corresponds to an uncorrectable error (eg, a 2-bit error on the same cache line) of the target page in expandable memory device 118, the AER processor of expandable memory device 118 may generate a Fault page information for the physical device information (eg, device serial number, device type, device physical address, etc.) of the target page of memory device 118 and the fault page information may be persistently stored in FPL 222 . Therefore, after a reboot or even in the event of a hardware configuration change, the fault page information stored in FPL 222 may be used to identify expandable memory devices that may need to be taken offline because the physical device information may remain relatively constant. 118 fault page. For example, the AER processor of expandable memory device 118 may initiate FPL daemon 216 to change the state of a fault page of expandable memory device 118 from a first state (eg, online or available state) to a second state (eg, offline). downtime or unavailable state) to take the target page offline based on fault page information persistently stored in FPL 222.

In some embodiments, because fault page information may be persistently stored in FPL 222, host device 102 may also provide an interface (eg, application programming interface (API)) to a user (eg, system administrator) such that Users have the ability to insert or delete fault page information in FPL222 for debugging purposes and/or for reliability, availability, and serviceability (RAS) feature compliance testing purposes. For example, because fault page information is used to automatically take a page offline after a system restart, hardware change, etc., a fault page may not be accessible after a system restart unless its fault page information is removed from FPL 222. Thus, in some embodiments, for example, the API may allow a user to remove a fault page from a fault page list such that the fault page may be accessed for testing purposes even after a system reboot or after a replacement of expandable memory device 118 .

3 is a flowchart of a method of generating a fault page log for an expandable memory device in accordance with one or more embodiments of the present disclosure.

For example, method 300 may be performed by processor 206 of host device 102 shown in FIG. 2 . However, the present disclosure is not limited in this regard, and the operations illustrated in method 300 may be performed by any suitable one of, or any suitable combination of, the components and elements of one or more embodiments described above. Furthermore, this disclosure is not limited to the order or number of operations of method 300 shown in FIG. 3 and may be changed to any desired order or number of operations as recognized by one of ordinary skill in the art. For example, in some embodiments, the order may vary, or method 300 may include fewer or additional operations.

Referring to Figures 2 and 3, method 300 may begin, and at block 305, a translation layer packet (TLP) may be received from an expandable memory device. For example, scalable memory device 118 may generate an error bit (eg, a 2-bit error) in the header of the TLP for the target page and may send the TLP to host device 102 (eg, root complex 202 ) accessing the target page. .

At block 310, erroneous bits in the TLP may be detected, and at block 315, an interrupt may be generated in response to detecting the erroneous bit. For example, in some embodiments, OS kernel 210 may receive a TLP from root complex 202 and may detect erroneous bits in the TLP. In response to detecting the error bit, the OS kernel 210 may generate an interrupt and may start the AER processor registered in the device driver 214 of the expandable memory device 118 .

At block 320, the fault page information may be persistently stored in the fault page log FPL. For example, as part of the interrupt routine of the AER processor of expandable memory device 118, the AER processor may transfer fault page information (e.g., device serial number, device type, device physical address, etc.) ) is stored in the FPL 222 and the FPL daemon 216 can be started.

At block 325, the faulty page may be taken offline in accordance with the FPL, and the method 300 may end. For example, FPL daemon 216 may read FPL 222 and may take fault pages of expandable memory device 118 offline based on the physical device information of expandable memory device 118 stored in FPL 222 . In response to taking the faulty page offline, any processes or applications accessing the faulty page may be terminated, and method 300 may end.

4 is a flowchart of a method of taking fault pages of an expandable memory device offline after a system restart, in accordance with one or more embodiments of the present disclosure.

For example, method 400 may be performed by processor 206 of host device 102 shown in FIG. 2 . However, the present disclosure is not limited in this regard, and the operations illustrated in method 400 may be performed by any suitable one of, or any suitable combination of, the components and elements of one or more embodiments described above. Furthermore, this disclosure is not limited to the order or number of operations of method 400 shown in FIG. 4 and may be changed to any desired order or number of operations as recognized by one of ordinary skill in the art. For example, in some embodiments, the order may vary, or method 400 may include fewer or additional operations.

Referring to Figures 2 and 4, method 400 may begin when the system is rebooted, such that at block 405, any boot processes (eg, startup processes) may be completed, and at block 410, the FPL daemon may is activated. For example, the reboot of the system may be performed by the OS kernel 210 of the host device 102 . For example, as mentioned above, in some embodiments, the FPL daemon 216 may be started after a system restart to automatically offline fault pages identified in the FPL 222 . For example, in some embodiments, FPL daemon 216 may be a background process initiated after startup is completed (eg, via registration in /etc/init.d/fpld), and at block 415 , FPL daemon 216 FPL 222 may be read (eg, from persistent storage device 218) to determine one or more faulty pages in one or more expandable memory devices. It should be noted that because the expandable memory device 118 may not include system key pages or memory types, the FPL 222 may not need to be updated during the memory initialization phase.

At block 420, the one or more faulty pages may be taken offline in accordance with the FPL, and the method 400 may end. For example, the FPL daemon 216 may, after a system restart (but before any memory mapping to each of the fault pages identified in the FPL 222 for each of the scalable memory devices 118 of the scalable memory pool 114), Each of the fault pages identified in the FPL 222 for each of the scalable memory devices 118 of the scalable memory pool 114 is automatically taken offline. Here, because the FPL 222 may include the physical device information of the faulty page, the faulty page may be identified even if the system memory mapping information (eg, logical address) is changed after a system restart. Therefore, error logs can be reduced, and user experience can be improved.

Figure 5 is a schematic block diagram of a scalable memory system in accordance with one or more embodiments of the present disclosure.

Referring to FIG. 5 , the scalable memory system may include a first host device (ie, host host device) 102a and a second host device (ie, guest host device) 102b each connected to a scalable memory pool 114 . For example, first host device 102a may be connected to scalable memory pool 114 via second memory interface 116 . The first host device 102a may be the same or substantially the same as the host device 102 described above, and therefore, redundant descriptions thereof may not be repeated. Similarly, the scalable memory pool 114 and the second memory interface 116 may be the same or substantially the same as those described above, and therefore, redundant descriptions thereof may not be repeated.

The second host device 102b may have a configuration similar to that of the host device 102 described above. For example, the second host device 102b may include a host operating system (OS)/kernel 104, a host processor 106, a host memory 108 connected via a first memory interface 112, and a storage device 110 connected via a storage interface, and thus, it Redundant descriptions may not be repeated. In some embodiments, the scalable memory pool 114 may be a network-attached scalable memory pool with respect to the second host device 102b. Accordingly, the second host device 102b may be connected to the expandable memory via a network interface (eg, a network interface controller or network interface card (NIC)) 502 through a suitable communications network (eg, the Internet, a wide area network, a local area network, a cellular network, etc.) Pool 114.

As described in greater detail below with reference to FIG. 6, in some embodiments, before accessing scalable memory devices 118a, 118b, and 118c of scalable memory pool 114, FPL daemon 216 of second host device 102b may communicate with the first host. Device 102a communicates to copy FPL 222 from first host device 102a and may use FPL 222 to offline fault pages for each of expandable memory devices 118a, 118b, and 118c before accessing expandable memory pool 114. Accordingly, the system memory map of the second host device 102b may exclude faulty pages in the FPL 222, and thus, error logs may be reduced and the user experience may be improved.

6 is a flowchart of a method of sharing fault page information of an expandable memory device according to one or more embodiments of the present disclosure.

For example, method 600 may be performed by processing circuitry 204 of second host device 102b shown in FIG. 5 (e.g., including a processor (ie, guest host processor) 206 and a memory 208 that stores instructions for execution by processor 206) , the processing circuit 204 may be the same or substantially the same as described above with reference to FIG. 2, and therefore, redundant description thereof may not be repeated. However, the present disclosure is not limited thereto, and the operations illustrated in method 600 may be performed by any suitable one, or any suitable combination of components and elements of one or more embodiments described above. Furthermore, this disclosure is not limited to the order or number of operations of method 600 shown in FIG. 6 and may be changed to any desired order or number of operations as recognized by one of ordinary skill in the art. For example, in some embodiments, the order may vary, or method 600 may include fewer or additional operations.

Referring to Figures 5 and 6, method 600 may begin, and at block 605, the FPL daemon may be started. For example, in some embodiments, the FPL daemon of the second host device 102b may be started before accessing the scalable memory pool 114. Here, because the system map (eg, logical map) of the first host device 102a may be different from the system map of the second host device 102b, the second host device 102b may start its FPL daemon 216 to copy the first host device 102a's system map. FPL 222. Accordingly, at block 610, fault page information may be requested from a main host (eg, first host device 102a), and at block 615, fault page information may be received from the main host. For example, the FPL daemon 216 of the second host device 102b may send a log request for fault page information stored in the FPL 222 of the first host device 102a to the first host device 102a, and the first host device 102a may respond The log request sends the fault page information (or FPL 222) stored in the FPL 222 of the first host device 102a to the second host device 102b.

At block 620, the FPL may be updated based on the received fault page information, and at block 625, one or more fault pages may be taken offline based on the FPL. For example, the second host device 102b may update its FPL 222 based on the received fault page information, and may cause one of each of the scalable memory devices 118a, 118b, and 118c of the scalable memory pool 114 based on the updated FPL 222 or Multiple failed pages are offline. Here, because the FPL 222 may include at least the physical device information of the fault page of the expandable memory device 118, even if the system mapping (eg, logical mapping) of the first host device 102a and the second host device 102b are different from each other, the second host device 102b 102b (eg, FPL daemon 222) may also take the fault page offline.

Accordingly, at block 630, the system map may be updated by excluding offline pages for the scalable memory pool, and the method 600 may end. For example, the second host device 102b may update (or may memory map) its system map based on the offline page before accessing the expandable memory pool 114 so that the faulty page of the expandable memory pool 114 may not be used by one of the second host device 102b Or accessed by multiple applications or processes. Therefore, error logs can be reduced, and user experience can be improved.

Figure 7 is a schematic block diagram of a scalable memory system in accordance with one or more embodiments of the present disclosure.

Referring to Figure 7, the scalable memory system may include a first host device 102a, a second host device 102b, a third host device 102c, etc., each connected to the scalable memory pool 114. For example, first host device 102a may be connected to scalable memory pool 114 via second memory interface 116 . The first host device 102a may be the same or substantially the same as the host device 102 described above, and therefore, redundant descriptions thereof may not be repeated. Similarly, the scalable memory pool 114 and the second memory interface 116 may be the same or substantially the same as those described above, and therefore, redundant descriptions thereof may not be repeated.

The second host device 102b and the third host device 102c may each have a configuration similar to that of the host device 102 described above. For example, in some embodiments, like host device 102 , second host device 102 b and third host device 102 c may each include a host operating system (OS)/kernel 104 , a host processor 106 , connected via first memory interface 112 The host memory 108, and the storage device 110 connected via the storage interface, and therefore, redundant descriptions thereof may not be repeated. In some embodiments, the scalable memory pool 114 may be a network-attached scalable memory pool with respect to the second host device 102b and the third host device 102c. Accordingly, the second host device 102b and the third host device 102c may each communicate via a suitable communications network (eg, the Internet, a wide area network, a local area network, a cellular network, etc.) via a network interface (eg, a network interface controller or a network interface card (NIC)). ) is connected to the scalable memory pool 114.

As shown in Figure 7, the second host device 102b may receive an erroneous bit (eg, a 2-bit error on the same cache line) UE generated by the third scalable memory device 118c in the scalable memory pool 114. In this case, the other host devices (eg, first host device 102a and third host device 102c) may not be aware of the target page because they may not be mapped to (or may not have access to) the target page of third expandable memory device 118c. An error occurred in the target page of the third expandable memory device 118c. Furthermore, because the system mapping (eg, logical mapping) of the first host device 102a and the third host device 102c may be different from the system mapping of the second host device 102b, the second host device 102b may send the updated FPL to the first host device 102b. At least one of the host device 102a and the third host device 102c.

For example, as described in greater detail below with reference to FIG. 8, in some embodiments, the second host device 102b (eg, the AER processor registered thereon corresponding to the third expandable memory device 118c) may respond to the error bit. Updates its FPL 222 and can start its FPL daemon 216 to take the faulted page offline. The FPL daemon 216 of the second host device 102b may communicate with the first host device 102a to send the updated FPL 222 to the first host device 102a. The first host device 102a may update its FPL 222 based on updates received from the second host device 102b and may broadcast the updates to other host devices registered with the first host device 102a to access the scalable memory pool 114 (e.g., Three host devices 102c, etc.).

In another embodiment, if the second host device 102b is communicating with other host devices (eg, the third host device 102c, etc.), the second host device 102b may directly broadcast the updates to the other host devices (eg, the first host device 102c, etc.) host device 102a and third host device 102c), instead of first sending the update to first host device 102a and first host device 102a broadcasting the update to the other remaining host devices (eg, third host device 102c, etc.). However, other suitable modifications may be possible depending on the implementation of the scalable memory system and the communication configuration between the host devices.

8 is a flowchart of a method of updating fault page information of an expandable memory device according to one or more embodiments of the present disclosure.

For example, method 800 may be performed by processing circuitry 204 of first host device 102a shown in FIG. 7 (eg, including processor 206 and memory 208 storing instructions for execution by processor 206), which may be as described above. The processing circuitry 204 of the host device 102 depicted in FIG. 2 is the same or substantially the same, and therefore, redundant descriptions thereof may not be repeated. However, the present disclosure is not limited in this regard, and the operations illustrated in method 800 may be performed by any suitable one, or any suitable combination of components and elements of one or more embodiment components and elements described above. Furthermore, this disclosure is not limited to the order or number of operations of method 800 shown in FIG. 8 and may be changed to any desired order or number of operations as recognized by one of ordinary skill in the art. For example, in some embodiments, the order may vary, or method 800 may include fewer or additional operations.

Referring to Figures 7 and 8, method 800 may begin, and at block 805, an update to the FPL may be received from the second host device. For example, in some embodiments, as shown in Figure 7, the second host device 102b may receive an error bit UE from the target page of the third expandable memory device 118c. The first host device 102a and the third host device 102c may not receive the error bit UE from the target page of the third expandable memory device 118c. For example, first host device 102a and third host device 102c may not be mapped to and/or may not access the target page of third expandable memory device 118c. In response to receiving the error bit UE from the target page of the third scalable memory device 118c, the second host device 102b may update its FPL 222 and may take the target page offline based on the updated FPL 222. The second host device 102b (eg, its FPL daemon 216) may send the update to the first host device 102a through a suitable communication interface.

At block 810, the FPL of the first host device may be updated based on the update. For example, the processor 206 (eg, FPL daemon 216) of the first host device 102a may update its FPL 222 based on updates received from the second host device 102b. At block 815, one or more faulty pages may be taken offline based on the updated FPL. For example, because the system map (eg, logical map) of the first host device 102a may be different from the system map of the second host device 102b, one or more faults identified from the updated FPL (eg, based on its physical device information) The page may be taken offline in the system map of the first host device 102a based on the updated FPL.

At block 820, the updated FPL may be broadcast to other registered daemons, and the method 800 may end. For example, the updated FPL may be broadcast by the FPL daemon 216 of the first host device 102a. For example, because the system mapping (eg, logical mapping) of other host devices (eg, third host device 102c, etc.) may be different from the system mappings of first host device 102a and second host device 102b, one or more faulty pages The physical device information may be broadcast so that the system maps of other host devices may be updated based on the updated FPL, and one or more faulty pages may be taken offline. Therefore, error logs can be reduced, and user experience can be improved.

According to one or more embodiments of the present disclosure described above, fault page information for each of the scalable memory devices of the scalable memory pool may be generated and persistently stored in a fault page list, and used as needed Or expect faulty pages to be taken offline automatically. According to one or more embodiments of the present disclosure described above, the fault page information may include at least physical device information of the fault page (eg, device serial number, device type, device physical address, etc.), such that even when the system mapping of the fault page Faulty pages can also be taken offline when the address (eg, logical address) is changed or different. Therefore, error logs can be reduced while extending the usable life of the scalable memory devices in the scalable memory pool.

While specific embodiments may be implemented differently, the specific order of processing may differ from that described. For example, two processes described in succession may be performed at the same time or substantially simultaneously, or may be performed in the reverse order of the order described.

It will be understood that, although the terms "first," "second," "third," etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or /or parts shall not be limited by these terms. These terms are used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. Thus, a first element, component, region, layer or section described above could be termed a second element, component, region or section without departing from the spirit and scope of the present disclosure. area, second level or second part.

It will be understood that when an element or layer is referred to as being "on," "connected to" or "coupled to" another element or layer, it can be directly on the other element or layer. layer, directly connected to, or directly coupled to another element or layer, or one or more intervening elements or layers may be present. Similarly, when a layer, region, or element is referred to as being "electrically connected" to another layer, region, or element, that layer, region, or element can be directly electrically connected to the other layer, region, or element, and/or can be electrically connected to the other layer, region, or element. An indirect electrical connection is made to another layer, region or element via one or more intervening layers, regions or elements. In addition, it will also be understood that when an element or layer is referred to as being "between" two elements or layers, that element or layer can be the only element or layer between the two elements or layers, or it may also be present. One or more intermediate elements or layers.

The terminology used herein is for the purpose of describing particular embodiments and is not intended to limit the disclosure. As used herein, the singular forms are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "comprising", "comprising" and "having", when used in this specification, indicate the presence of the recited features, integers, steps, operations, elements and/or components but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. For example, the expression "A and/or B" means A, B, or A and B. Expressions such as "at least one of," when preceding a list of elements, modify the entire list of elements but do not modify the individual elements in the list. For example, the expressions "at least one of a, b, or c", "at least one of a, b, and c", and "at least one selected from the group consisting of a, b, and c" indicate: only a, Only b, only c, both a and b, both a and c, both b and c, all a, b and c or variations thereof.

As used herein, the terms "substantially," "about," and similar terms are used as terms of approximation rather than terms of degree, and are intended to account for inherent deviations in measured or calculated values that one of ordinary skill in the art will recognize. Additionally, the use of "may" when describing embodiments of the disclosure means "one or more embodiments of the disclosure." As used herein, the terms "use," "being used," and "being used" may be considered synonymous with the terms "utilizing," "utilizing," and "being utilized," respectively. Furthermore, the term "exemplary" is intended to mean an example or illustration.

Electronic or electrical devices and/or any other related devices or components according to embodiments of the disclosure described herein may utilize any suitable hardware, firmware (eg, application specific integrated circuits), software, or a combination of software, firmware and hardware. combination to achieve. For example, the various components of these devices may be formed on one integrated circuit (IC) chip or on separate IC chips. Additionally, the various components of these devices may be implemented on a flexible printed circuit film, a tape carrier package (TCP), a printed circuit board (PCB), or formed on a substrate. Additionally, various components of these devices may be processes running on one or more processors in one or more computing devices that execute computer program instructions and interact with other system components to perform the various functions described herein, or thread. Computer program instructions are stored in memory, which may be implemented in a computing device using standard memory devices, such as, for example, random access memory (RAM). Computer program instructions may also be stored in other non-transitory computer-readable media (such as, for example, CD-ROMs, flash drives, etc.). Additionally, those skilled in the art will recognize that the functionality of various computing devices may be combined or integrated into a single computing device, or the functionality of a particular computing device, without departing from the spirit and scope of example embodiments of the present disclosure. Can be distributed across one or more other computing devices.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will also be understood that, unless expressly so defined herein, terms (such as terms defined in a general dictionary) are to be construed to have a meaning consistent with their meaning in the context of the relevant art and/or in this specification, and It should not be interpreted in an idealized or overly formal sense.

Although a few embodiments have been described, those skilled in the art will readily appreciate that various modifications are possible in the embodiments without departing from the spirit and scope of the disclosure. It will be understood that descriptions of features or aspects within each embodiment should generally be considered as available for other similar features or aspects in other embodiments, unless otherwise described. Accordingly, it will be apparent to one of ordinary skill in the art that, unless otherwise specifically indicated, features, characteristics and/or elements described in connection with a particular embodiment may be used alone or with features, characteristics and/or elements described in connection with other embodiments. and/or used in combination with components. It will be understood, therefore, that the foregoing is a description of various example embodiments and is not to be construed as limitations on the particular embodiments disclosed herein, and that various modifications to the disclosed embodiments as well as other example embodiments are intended to be It is intended to be included within the spirit and scope of the disclosure as defined in the appended claims and their equivalents.

Claims (20)

1. A system for processing a failed page, comprising:

a host processor;

a host memory connected to the host processor through a first memory interface; and

an expandable memory pool connected to the host processor through a second memory interface, the second memory interface being different from the first memory interface,

wherein the host memory includes instructions that, when executed by the host processor, cause the host processor to:

detecting an error in a target page of a first memory device of the scalable memory pool;

generating an interrupt in response to detecting the error;

storing fault page information corresponding to a target page of the first memory device in a fault page log; and is also provided with

The state of the target page of the first memory device is changed from the first state to the second state according to the fault page log.

2. The system of claim 1, wherein the second memory interface comprises: peripheral component interconnect express interfaces and computing express link interconnects.

3. The system of claim 2, wherein the first memory interface comprises: a dual inline memory module.

4. The system of claim 1, wherein the scalable memory pool comprises at least two different types of computing fast link memory devices.

5. The system of claim 1, wherein the instructions further cause the host processor to:

performing a restart;

reading the fault page log to identify one or more fault pages of the scalable memory pool; and is also provided with

And setting a second state of the one or more fault pages according to the fault page log.

6. The system of claim 1, wherein the instructions further cause the host processor to:

receiving a log request for a fault page log from a guest host processor, the guest host processor configured to access an extensible memory pool; and is also provided with

In response to the log request, a fault page log is sent to the guest host processor,

wherein the guest host processor is configured to: a second state of one or more pages of the scalable memory pool is set based on the fault page log.

7. The system of claim 1, wherein the instructions further cause the host processor to:

receiving an update from a first guest host processor, the first guest host processor detecting an error in a second memory device in the scalable memory pool;

identifying a failed page of the second memory device based on the update;

updating a fault page log; and is also provided with

Based on the updated fault page log, a second state of the fault page of the second memory device is set.

8. The system of claim 7, wherein the instructions further cause the host processor to:

the updated fault page log is broadcast to a second guest host processor configured to access the scalable memory pool.

9. The system of any of claims 1 to 8, wherein the error in the target page of the first memory device of the scalable memory pool is a multi-bit error in the target page of the first memory device of the scalable memory pool, and the failed page information includes physical device information of the target page of the first memory device.

10. A method of handling a failed page, comprising:

detecting, by a kernel of a first host device, an error in a target page of a first memory device of the scalable memory pool;

generating, by the kernel, an interrupt in response to detecting the error;

storing, by a device driver corresponding to the first memory device, fault page information corresponding to a target page of the first memory device in a fault page log; and

the state of the target page of the first memory device is changed from the first state to the second state by the fault page log FPL daemon according to the fault page log.

11. The method of claim 10, wherein a first memory device of the scalable memory pool is connected to the first host device via a peripheral component interconnect express interface and a computing express link interconnect.

12. The method of claim 10, wherein the scalable memory pool comprises at least two different types of computing fast link memory devices.

13. The method of claim 10, further comprising:

performing a reboot by the kernel;

reading, by the FPL daemon, the fault page log to identify one or more fault pages of the scalable memory pool; and

a second state of the one or more failed pages is set by the FPL daemon according to the failed page log.

14. The method of claim 10, further comprising:

receiving, by the FPL daemon of the first host device, a log request for a fault page log from the FPL daemon of the second host device, the second host device configured to access the scalable memory pool; and

in response to the log request, a fault page log is sent by the FPL daemon of the first host device to the second host device,

wherein the FPL daemon of the second host device is configured to: a second state of one or more failed pages of the scalable memory pool is set based on the failed page log.

15. The method of claim 10, further comprising:

in response to the second host device detecting an error in the second memory device in the scalable memory pool, receiving, by the FPL daemon of the first host device, an update from the FPL daemon of the second host device;

identifying, by the FPL daemon of the first host device, a failed page of the second memory device according to the update;

updating, by the FPL daemon of the first host device, the fault page log; and

the second state of the failed page of the second memory device is set by the FPL daemon of the first host device based on the updated failed page log.

16. The method of claim 15, further comprising: the updated fault page log is broadcast by the FPL daemon of the first host device to a third host device configured to access the scalable memory pool.

17. The method of any of claims 10 to 16, wherein the error in the target page of the first memory device of the scalable memory pool is a multi-bit error in the target page of the first memory device of the scalable memory pool, and the failed page information comprises physical device information of the target page of the first memory device.

18. A host device, comprising:

a root complex connected to the scalable memory pool through a memory interface and configured to parse packets received from a memory device of the scalable memory pool;

a core configured to detect an error bit corresponding to a failed page of the first memory device from the parsed packet and generate an interrupt in response to detecting the error bit;

a driver of the first memory device configured to store, in response to the interrupt, fault page information corresponding to a fault page of the first memory device in a fault page log; and

the fault page log daemon is configured to change a state of a fault page from a first state to a second state based on the fault page log.

19. The host device of claim 18, wherein the scalable memory pool comprises at least two different types of computing fast link memory devices.

20. The host device of claim 18, wherein, in response to restarting, the FPL daemon is configured to: the fault page log is read to identify one or more fault pages of the scalable memory pool, and a second state of the one or more fault pages is set according to the fault page log.