A memory fault identification method and a memory fault isolation method

Abstract

The specification provides a memory fault identification method and a memory fault isolation method, a fault database is pre-configured, the fault database records the fault records of the whole life cycle of all memory units, and each memory unit fault record at least includes the number of CEs occurring in the whole life cycle of the memory unit; in the case of a correctable error CE of a memory unit, the fault database is updated; for each memory unit, in the case that the number of CEs occurring in the whole life cycle of the memory unit in the fault database exceeds the number threshold, it is determined that the memory unit has a hard fault. By recording the fault database of the number of CEs of each memory unit in the whole life cycle, the isolation of the memory fault can improve the accuracy and coverage of the isolation, reduce the probability of misidentifying soft fault as hard fault, and improve the probability of isolating hard fault.

Description

Technical Field

[0001] This specification relates to the field of terminal technology in one or more embodiments, and in particular to a memory fault identification method and a memory fault isolation method. Background Technology

[0002] Memory failure is a significant factor affecting computer performance. When a memory failure is detected, the memory page corresponding to the faulty address needs to be taken offline (meaning the operating system can no longer write data to that memory page; the offline memory page is then isolated) to prevent the computer from accessing that memory page and thus affecting its performance.

[0003] Memory faults are divided into Permanent Fault (also known as hard fault) and Transient Fault (also known as soft fault). Soft fault is a transient fault that will recover after a period of time, so soft fault does not need to be isolated. What needs to be isolated is hard fault, which occurs repeatedly.

[0004] From the operating system's perspective, when a memory cell fails, the operating system reports a correctable error (CE). In other words, regardless of whether it's a hard fault or a soft fault, the operating system will report a CE upon detection, and the operating system cannot distinguish between the two types of faults.

[0005] In related technologies, hard faults are generally identified through a daemon process. Since hard faults are repetitive, if a memory page experiences two Complete Errors (CEs) within a certain period of time (e.g., 24 hours), the daemon considers that the memory page to have a hard fault.

[0006] However, the methods for identifying hard faults in related technologies are not accurate. For some fields with high memory capacity or high performance requirements, this method of identifying hard faults will affect the running performance or cause the memory capacity to be insufficient. Summary of the Invention

[0007] In view of this, one or more embodiments of this specification provide a memory fault identification method and a memory fault isolation method.

[0008] According to a first aspect of one or more embodiments of this specification, a memory fault identification method is proposed, comprising: pre-configuring a fault database, wherein the fault database records fault records for the entire lifecycle of all memory units, and each memory unit fault record includes at least the number of times a Complete Execution (CE) occurs during the entire lifecycle of that memory unit; the method includes:

[0009] In the event of a correctable error (CE) in a memory cell, update the fault database;

[0010] For each memory cell, if the number of CE (Complete Error) events occurring during the entire lifecycle of that memory cell in the fault database exceeds a certain threshold, then that memory cell is determined to have a hard fault.

[0011] According to a second aspect of one or more embodiments of this specification, a memory fault isolation method is provided, the method comprising:

[0012] Based on the memory fault identification method described above, the fault result of each memory unit is determined; the result type of each memory unit is used to characterize whether a hard fault exists in each memory unit.

[0013] Based on the fault results of the memory cells corresponding to each memory page, the faulty memory page is determined; wherein, the probability that the fault in the faulty memory page causes an uncorrectable UE error is greater than the probability threshold.

[0014] Isolate the faulty memory page.

[0015] According to a third aspect of the embodiments of this specification, a memory fault identification device is provided, which pre-configures a fault database, wherein the fault database records fault records for the entire lifecycle of all memory units, and each memory unit fault record includes at least the number of times a fault identification (CE) occurs during the entire lifecycle of that memory unit; the device includes:

[0016] The fault database update module is used to update the fault database when a correctable error (CE) occurs in a memory cell.

[0017] The memory fault identification module is used to determine if a memory cell has a hard fault if the number of CE (Complete Error) events during the entire lifecycle of the memory cell exceeds a certain threshold in the fault database.

[0018] According to a fourth aspect of the embodiments of this specification, a memory fault isolation device is provided, the device comprising:

[0019] The fault result determination module is used to determine the fault result of each memory unit according to the aforementioned fault identification method; the result type of each memory unit is used to characterize whether a hard fault exists in each memory unit.

[0020] The faulty memory page determination module is used to determine the faulty memory page based on the fault results of the memory cells corresponding to each memory page; wherein, the probability that the faulty memory page causes an uncorrectable error UE is greater than a probability threshold.

[0021] A memory page isolation module is used to isolate the faulty memory page.

[0022] According to a fifth aspect of the embodiments of this specification, a memory fault isolation system is provided, the memory fault isolation system including a plurality of servers and a central device for managing the plurality of servers;

[0023] In the event of a CE (Collapse Detection), the server will report the CE to the central device.

[0024] The central device is at least used to identify memory cells with hard faults using the memory fault identification method described above, or to determine memory pages that need to be isolated using the memory fault isolation method described above, and to notify the server to isolate the memory page.

[0025] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored, which, when executed by a processor, implement the memory fault identification method or the memory fault isolation method described above.

[0026] According to a seventh aspect of the embodiments of this specification, an electronic device is provided, comprising:

[0027] processor;

[0028] Memory used to store processor-executable instructions;

[0029] The processor implements the memory fault identification method or the memory fault isolation method described above by running the executable instructions.

[0030] This specification provides a memory fault identification method and a memory fault isolation method. A fault database is pre-configured, which records fault records for the entire lifecycle of all memory units. Each memory unit fault record includes at least the number of Correctable Errors (CEs) that occur during the entire lifecycle of the memory unit. When a correctable error (CE) occurs in a memory unit, the fault database is updated. For each memory unit, if the number of CEs that occur during the entire lifecycle of the memory unit in the fault database exceeds a threshold, it is determined that the memory unit has a hard fault.

[0031] Isolating memory faults by using a fault database that records the number of CE (Complete Error) events throughout the entire lifecycle of each memory unit can improve the accuracy and coverage of isolation, reduce the probability of soft faults being misidentified as hard faults, and increase the probability of hard faults being isolated.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0034] Figure 1 This is a flowchart illustrating a memory fault isolation method according to the relevant technology shown in this specification.

[0035] Figure 2A This is a flowchart illustrating a memory fault identification method according to an exemplary embodiment of this specification.

[0036] Figure 2B This is a schematic diagram illustrating a type of fault according to an exemplary embodiment of this specification.

[0037] Figure 3 This is a flowchart illustrating a memory fault isolation method according to an exemplary embodiment of this specification.

[0038] Figure 4A This is a schematic diagram illustrating a memory fault isolation method according to a specific embodiment of this specification.

[0039] Figure 4B This is a flowchart illustrating a memory fault isolation method according to a specific embodiment of this specification.

[0040] Figure 5 This is a block diagram illustrating a memory fault identification device according to an exemplary embodiment of this specification.

[0041] Figure 6 This is a block diagram illustrating a memory fault isolation device according to an exemplary embodiment of this specification.

[0042] Figure 7 This specification is a hardware structure diagram of an electronic device containing a memory fault identification device or a memory fault isolation device, according to an exemplary embodiment. Detailed Implementation

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0044] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0045] Memory is one of the most important components of a computer. It acts as a bridge between the processor (Central Processing Unit, CPU) and the computer itself. All programs run in memory, and memory performance has a significant impact on the computer's performance. Memory, also known as internal memory, is used to temporarily store data processed by the CPU and to exchange data with external storage devices (such as hard drives). Whenever the computer is running, the CPU loads the data it needs to process into memory, performs the calculations, and then retrieves the results.

[0046] Memory can fail. A memory failure occurs when a memory cell remains at a high or low voltage level (in other words, the smallest unit of memory failure is a memory cell), and its state cannot be modified. Memory failures are generally divided into hard faults and soft faults. A hard fault is a fault that occurs repeatedly at the same address, indicating that the memory cell corresponding to that address is damaged. A soft fault is a random fault, typically occurring only once at a given address. This type of fault is usually caused by temporary damage to the memory cell due to high-energy radiation or electromagnetic interference.

[0047] If a memory cell is damaged, the operating system will be unable to access it normally if it uses that damaged memory cell. Therefore, when a memory cell detects this situation, it will report a CE (Error Correction) error and use an error correction algorithm to find other available memory cells. Furthermore, the presence of too many faults may lead to uncorrectable errors (UEs). If the memory page corresponding to a UE is used by the kernel, it may cause the system to crash.

[0048] As we can see, the presence of damaged memory cells will impact the performance of the operating system, and too many memory failures may even lead to system crashes. Therefore, in the event of a memory failure, it is necessary to isolate the faulty memory cell, preventing the operating system from accessing it. This ensures the operating system's execution efficiency and avoids excessive impact from the user experience (UX) on the operating system.

[0049] Soft faults are random failures, meaning they recover after a period of time. Therefore, soft faults do not require isolation; what needs isolation are hard faults that cause substantial damage. Thus, the operating system needs to distinguish between hard and soft faults to isolate memory failures. From the operating system's perspective, since soft faults are transient—occurring only once per memory cell—while hard faults are permanent and occur more frequently, the frequency of reported Memory Errors (CEs) can be used to differentiate between them.

[0050] In related technologies, the flowchart for daemon process identification of hard faults is as follows: Figure 1 As shown, when a hardware report of a CE occurs, the daemon process will determine whether the number of CEs for the memory page corresponding to the reported CE is greater than or equal to 2 within a predetermined time (usually 24 hours). If it is greater than or equal to 2, the kernel's page offline interface will be called to take the memory page offline.

[0051] This method has the following problems: In related technologies, the daemon process runs in the kernel. In order to reduce the impact of the daemon process on the system execution efficiency, the daemon process cannot occupy too many resources. Therefore, this fault isolation method is based on a simple threshold for identification, which may result in low identification accuracy and low coverage.

[0052] Specifically, firstly, because it's based on memory page lookups, and a memory page contains many memory units, two fault reports (CEs) occurring within a memory page within a certain timeframe might be reported from different memory units. There's a certain probability that both CEs are the first CE occurrence for the corresponding memory unit, which could incorrectly identify a soft fault as a hard fault. If memory pages are further isolated, the memory pages corresponding to the resulting CEs would be isolated, wasting the host's available memory.

[0053] Secondly, since it is based on memory page lookup, if the pre-set time (the pre-set time mentioned above) is too long, it will lead to a high lookup error rate (because the longer the time, the more soft faults occur in the memory cells of this memory page). Therefore, in order to reduce the error rate and reduce the memory occupied by the daemon process, the pre-set time is generally relatively short (usually 24 hours). The CE event is only triggered when a memory cell with a hard fault is accessed. The access is a relatively random process, which may take several minutes, several days, or even several months to be accessed consecutively. The limitation that the pre-set time cannot be too long makes it impossible to detect a large number of hard faults.

[0054] Furthermore, if the approach to handling a hard fault is to isolate memory pages, the following problems arise: Isolating memory pages is typically achieved by calling the kernel's page offline interface. Since page offline is not a try-best approach, memory page isolation may fail in some cases. For example, if a memory page is being used by a process within the kernel, it cannot be isolated successfully. Therefore, the methods used in related technologies have a low success rate for memory page isolation.

[0055] While memory fault isolation methods in related technologies are not highly accurate in most application scenarios, they have minimal impact on system operation and are therefore relatively effective. However, in scenarios with high memory stability requirements and where it is desirable for the actual memory capacity to be as close as possible to the nominal value, these methods may misidentify soft faults as hard faults. This can lead to the incorrect isolation of memory pages that do not require isolation, resulting in a smaller actual memory capacity. Furthermore, these methods may miss some hard faults, allowing faulty memory cells to affect memory stability and ultimately impact system performance.

[0056] For example, in public cloud computing scenarios, firstly, they have high requirements for system performance, and in large-scale cloud computing scenarios, service impairment (service unavailability, service degradation) caused by memory failures accounts for the top two proportions, making it a key factor affecting the stability of elastic computing; secondly, because the capacity of each memory module on a single server in a cloud computing scenario is large, the failure rate of each memory module is higher due to limitations in memory manufacturing processes, resulting in a higher number of CE and UE failures on a single server; moreover, in cloud computing scenarios, a single server hosts a large number of services, so if a server experiences CE or UE, the number of services that may be affected is also high. Therefore, it is more sensitive to memory failures, and there is a need to identify all hard faults; thirdly, for public clouds, cloud computing services are rented to different users, and users expect the service they purchase to be closer to the nominal value. Therefore, in public cloud computing scenarios, it is preferred that the actual memory capacity be closer to the nominal value, meaning that it is less acceptable to misidentify a soft fault as a hard fault and then isolate the memory page where the soft fault is located.

[0057] Based on the above reasons, for public cloud computing scenarios, there is a need for a memory fault identification and handling method with higher accuracy, coverage (i.e., time range for finding CE), and success rate.

[0058] Based on this, this specification considers the first two shortcomings of related technologies and proposes that instead of setting up a daemon process in the kernel, fault isolation analysis can be performed in user space, that is, collecting CE data to form a fault database for the entire life cycle (although this process may be more time-consuming than related technologies and the fault database occupies a certain amount of storage space, compared with the greater impact on UE, the method in this specification only consumes a certain amount of memory and storage space to complete the identification of hard faults to avoid greater harm). The number of times CE occurs in each memory unit is determined based on the fault database, thereby determining whether a hard fault has occurred in each memory unit.

[0059] Furthermore, regarding fault handling, if the method of isolating memory pages from related technologies is adopted, it's worth noting that if only one memory cell within a memory page experiences a hard fault, the likelihood of that memory page causing a UE (User Equipment) is low. Moreover, different memory cells within a memory page may be distributed across different memory modules. Simply analyzing the faults of individual memory cells within a memory page makes it difficult to determine whether a fault could lead to a UE. Therefore, faults can be further classified at different levels. For example, they can be classified at the bank level, determining the bank's fault type based on the faults of individual memory cells and their physical relationships. This allows for determining whether to isolate the memory pages mapped to each bank based on its fault type. Furthermore, the fault type of each memory bank within a Dual-Inline-Memory-Module (DIMM) can be used to determine the fault type of each DIM (Digital In-line Memory Module), further determining whether memory repair is necessary.

[0060] In addition, this manual can also determine the severity of a fault based on the fault results of each memory unit included in each memory page, thereby achieving the isolation of memory pages. For memory pages with minimal impact, isolation can be omitted, thus allowing users of the rental service to have more available memory space.

[0061] Finally, for the try-best page offline interface, page offline can be executed repeatedly until isolation is successful, which improves the success rate of isolation.

[0062] In other words, this specification provides a memory fault identification method and a memory fault isolation method. A fault database is pre-configured, which records fault records for the entire lifecycle of all memory units. Each memory unit fault record includes at least the number of Correctable Errors (CEs) that occur during the entire lifecycle of the memory unit. When a correctable error (CE) occurs in a memory unit, the fault database is updated. For each memory unit, if the number of CEs that occur during the entire lifecycle of the memory unit in the fault database exceeds a threshold, it is determined that the memory unit has a hard fault.

[0063] Isolating memory faults by using a fault database that records the number of CE (Complete Error) events throughout the entire lifecycle of each memory unit can improve the accuracy and coverage of isolation, reduce the probability of soft faults being misidentified as hard faults, and increase the probability of hard faults being isolated.

[0064] In other words, compared to related technologies that identify hard faults at the memory page level, the method provided in this specification identifies hard faults at the memory cell level, reducing the probability of soft faults being mistakenly isolated. Furthermore, by using a fault database that records the number of CEs (Complete Errors) throughout the entire lifecycle of each memory cell to determine whether a hard fault exists in each memory cell, it considers more historical data, and can identify hard faults even if a memory cell has not been accessed for a long time.

[0065] The memory fault identification methods provided in this manual will be explained in detail below. Figure 2A As shown, Figure 2A This is a flowchart illustrating a memory fault identification method according to an exemplary embodiment, comprising the following steps:

[0066] Step 201: In the event of a correctable error (CE) in a memory cell, update the fault database.

[0067] Before executing the above method, a fault database is pre-configured, which records fault records for the entire lifecycle of all memory units. Each memory unit fault record includes at least the number of times a Complete Execution (CE) occurs during the entire lifecycle of that memory unit.

[0068] In other words, the fault database stores fault records throughout the entire lifecycle at the memory unit level. By accessing the fault database, the historical fault records of each memory unit can be obtained, thereby determining which memory unit is damaged.

[0069] The following will explain several terms involved in step 201.

[0070] First, let's introduce the concept of a memory unit, also known as a memory cell. Memory units are arranged in a matrix in memory. Each row and each column corresponds to a row address line (word line) and a column address line (bit line). Each cell corresponds to a row address line and a column address line. The memory address is determined by the row and column numbers corresponding to that cell.

[0071] For details on CE and memory failures, please refer to the description above. It should be noted that in this article, "fault" refers to a physical failure of the memory, and "error" refers to a problem encountered during the operation of the operating system.

[0072] The following will explain the terms related to the fault database. The entire lifecycle refers to all records since the server started running / being put into use. The fault database is a new database added to the methods provided in this manual for storing fault records. In addition to storing the number of CEs (Error Detection) occurring within the entire lifecycle of each memory unit, it can also store the original log file of the CE or CE records output in a specified format; or, after determining whether a hard fault exists in each memory unit, it can store whether a hard fault exists in each memory unit; and, after determining the fault type (error pattern) of each memory unit, it can store the fault type of each memory unit. Furthermore, the number of CEs occurring within the entire lifecycle of a memory unit refers to CEs reported that are caused by a fault in that memory unit.

[0073] For the fault database, updating the fault database means updating the data stored in the fault database according to the CE (Case Error). If the fault database only stores the number of CEs that occur during the entire lifecycle of each memory unit, then if any memory unit causes a CE, the number of CEs that occur during the entire lifecycle of that memory unit is incremented by 1. Other cases (where the fault database also stores other data) are similar and will not be elaborated here.

[0074] It should also be noted that when the memory module is replaced, the corresponding fault database should also be reset along with the memory module to make the records in the fault database more accurate.

[0075] After explaining the various words and phrases involved in step 201, the following will describe a specific implementation of step 201. Of course, the specific implementation of step 201 is not limited to this.

[0076] In related technologies, daemons run in the kernel and read and write data within it. Since writing to kernel data is risky and can easily cause system crashes, the method described in this specification can be applied to user space to avoid this. This way, only kernel data reading operations are required, and the fault database is not located in the kernel, eliminating the need for kernel writes. Furthermore, to ensure that user-space processes are aware of fault occlusion (CE), the method in this specification also includes listening for and reporting CEs, and then outputting CE records in a prescribed format, allowing user-space processes to be aware of CE occurrences.

[0077] In other words, step 201 specifically includes: obtaining the log file corresponding to the CE that occurred in the memory cell; parsing the obtained log file and outputting a fault record in a predetermined format; the fault record in the predetermined format includes at least the address of the memory cell in which the CE occurred; storing the fault record in the predetermined format in the fault database and updating the number of times the corresponding memory cell in the fault database has experienced a CE.

[0078] Step 203: For each memory cell, if the number of CE (Complete Error) events occurring during the entire lifecycle of the memory cell in the fault database exceeds the threshold, then the memory cell is determined to have a hard fault.

[0079] In other words, by comparing the number of times each memory cell experiences a CE (Complete Error) over its entire lifecycle with a threshold number, memory cells that exceed the threshold number are identified as having hard faults, and these hard faults can be addressed.

[0080] First, it's necessary to explain why the number of CE (Critical Error Detection) events is compared to the threshold. For memory faults, unless the memory module is removed from the host and tested by the machine, it's impossible to determine whether the fault in each memory cell is a hard fault or a soft fault. Therefore, considering that a soft fault is a temporary damage and a hard fault is a permanent one, the probability of a soft fault being accessed multiple times by the system within the faulty period is low, and the probability of the same memory cell experiencing multiple soft faults is also low. Therefore, memory cells that have experienced only a few CE events can be considered to have had soft faults, while memory cells that have experienced multiple CE events are classified as having hard faults.

[0081] The threshold for the number of occurrences can be set as needed, and can be set to 2. When the server runs for a long time, considering that the probability of a soft fault occurring in each memory unit will increase, the threshold for the number of occurrences can also be set to any value greater than 2.

[0082] Regarding the timing of the execution of steps 201 and 203, step 203 can be executed after step 201 updates the fault database. Alternatively, the timing of step 203 can be independent of step 201, such as step 203 being executed on a cycle independent of step 201.

[0083] Furthermore, it should be noted that the more accurate detection of hard faults in this manual is based on the combined effect of detection throughout the entire lifecycle and detection at the memory unit level. If only one of the two methods is used, the accuracy of hard fault identification cannot be improved.

[0084] Specifically, if fault detection is performed at the memory page level based on fault records throughout the entire lifecycle, more soft faults may be misidentified as hard faults because different memory units within a memory page have a high probability of occurring, further reducing the available memory space. If hard fault detection is performed at the memory unit level based on fault records within a certain time period, some hard faults may not be identified due to the short time frame, resulting in missed detections of hard faults.

[0085] The above method identifies hard faults by counting the number of CE (Complete Error) events in each memory unit throughout its entire lifecycle. Because the number of CE events is recorded at the memory unit level, the probability of misidentifying a soft fault as a hard fault is reduced. Furthermore, since hard fault detection is based on the entire lifecycle, the coverage of hard fault identification is improved, making it easier to identify hard faults.

[0086] In addition, after identifying a hard fault, other fault types can be further identified to enrich the fault database records in order to assess the fault severity of each memory unit and prepare for subsequent fault handling.

[0087] Physically, a memory bank consists of several memory cells, and the physical location of each memory cell within the bank affects the severity of the fault. For example, even with the same number of memory cells exhibiting hard faults, the different distributions of these faulty cells can lead to varying degrees of severity. Therefore, based on the fault results and physical location of each memory cell within the bank, the fault type of each memory bank can be determined at the bank level. This allows us to identify the fault type within the bank and, based on the fault type of the memory bank, determine the likelihood that a fault in each memory page might affect system operation, further assessing the probability that it will trigger a user experience (UE).

[0088] In other words, the method further includes: for each memory bank, determining the fault type of the memory bank based on the fault records of the memory cells throughout their entire lifecycle and the physical location relationship of each memory cell in the fault database; the fault type of the memory bank is used to characterize the severity of the memory bank fault.

[0089] For example, combining Figure 2B This explains how to specifically determine the type of memory bank failure. Among other things, Figure 2B The large boxes represent a memory cell, the small squares represent memory locations where a CE (Complete Error) occurred, and the numbers next to them represent the number of times a CE occurred. Figure 2B In this case, n is any value greater than 1.

[0090] If only a small number (e.g., one) of the memory cells in a memory bank have experienced Complete Execution (CE), and there is no hard fault in the memory cell that experienced CE, then the fault type of that memory cell can be considered a single fault. This fault type indicates that the fault in the memory bank is not severe. This situation applies when the frequency threshold is 1. Figure 2B As shown in (a).

[0091] If a memory bank has only a small number of memory cells that have experienced a Complete Execution (CE) (and there are no fault rows or columns), but among the memory cells that have experienced CE, at least one memory cell has a hard fault, then the fault type of the memory bank can be determined to be a recurring fault. A recurring fault is slightly more serious than a single fault. This situation occurs when the frequency threshold is 1, such as... Figure 2B As shown in (b).

[0092] In other words, if the number of memory cells in the memory bank that have experienced a Completely Executable (CE) error is less than a first threshold, and at least one memory cell that has experienced a CE has a hard fault, then the fault type of the memory bank is determined to be a recurring fault. The first threshold can be chosen according to actual needs; for example, it can be 2, or other values. This specification does not limit this choice.

[0093] If a memory bank contains multiple memory cells in a row or column that have experienced Complete Execution (CE) events, and none of these CE-involved memory cells contain hard faults, then the memory bank is considered to have a faulty row or column. If a memory bank contains a faulty row or column (but no severely faulty rows or columns), then the fault type of the memory bank is considered a row fault / column fault. Row faults / column faults are slightly more serious than repeated faults. This situation occurs when the count threshold is 1, such as... Figure 2B As shown in (c).

[0094] In other words, if there is a faulty row or faulty column in the memory bank, then the fault type of the memory bank is determined to be a row or column fault; the number of memory cells that have experienced a CE in the faulty row or faulty column is greater than or equal to a first quantity threshold, and there is no hard fault in the faulty row or faulty column.

[0095] If a row or column contains multiple memory cells that have experienced a Completely Executable (CE) fault, and at least one memory cell contains a hard fault, then the memory bank is considered to have a critically faulty row or column. If the number of critically faulty rows or columns does not exceed a second threshold, then the fault type of the memory bank is considered a critical row fault / critical column fault, which is more severe than a row fault / column fault. This situation occurs when the count threshold is 1. Figure 2B As shown in (d).

[0096] In other words, if there is a critical fault row or critical fault column in the memory bank, and the number of critical fault rows and / or critical fault columns is less than a second quantity threshold, then the fault type of the memory bank is determined to be a critical row or column fault; the number of memory cells in the critical fault row or critical fault column that have experienced a CE is greater than or equal to a first quantity threshold, and at least one memory cell in the critical fault row or critical fault column has a hard fault.

[0097] Furthermore, if a large number of memory cells in the memory bank have experienced Complete Execution (CE) events (e.g., more than 100), and the total number of rows and columns containing these CE-affected memory cells exceeds a significant threshold (e.g., more than 50), then the memory cell is considered to have a serious fault. A serious fault is more severe than a serious row fault or a serious column fault. This situation occurs when the frequency threshold is 1. Figure 2B As shown in (e).

[0098] In other words, if the number of memory cells that have experienced a Complete Execution (CE) in the memory bank is greater than a third threshold, and the total number of rows and columns that have experienced a CE is greater than a fourth threshold, then the fault type of the memory bank is determined to be a serious fault; the third threshold is greater than the first threshold, and the fourth threshold is greater than the second threshold.

[0099] Furthermore, the method for determining the fault type of a memory bank is not limited to this; it can also be determined based on other methods. This specification does not limit the method for determining the fault type of a memory bank.

[0100] This allows us to determine the fault type of each faulty memory bank, thus better assessing the severity of the memory cell fault.

[0101] Furthermore, considering that several memory libraries form a DIMM, the fault type can be further identified based on the DIMM level, so that when the fault in the entire DIMM is more serious, the entire DIMM can be processed.

[0102] In other words, the method further includes: for each dual in-line memory module (DIMM), determining the fault type of the DIMM based on the fault types of each memory bank contained in the DIMM; the fault type of the DIMM is used to characterize the severity of the DIMM fault.

[0103] Specifically, based on the fault types in the memory database, including single fault, repeated fault, row fault, column fault, severe row fault, severe column fault, and severe fault, the fault type of DIMM can be determined using the following scheme:

[0104] If only one memory bank in the entire DIMM is faulty, and the fault type of that memory bank is a single fault, then the fault type of that DIMM is determined to be a simple single fault.

[0105] If multiple memory banks in a DIMM have failed, and all of these memory banks have a single type of failure, then the failure type of that DIMM is determined to be a mixed single failure. A mixed single failure is more severe than a simple single failure.

[0106] If only one memory bank in the entire DIMM is faulty, and the fault type of that memory bank is a recurring fault, then the fault type of that DIMM is determined to be a simple recurring fault. Simple recurring faults are more severe than mixed single faults.

[0107] If multiple memory banks in a DIMM have faults, and the most severe fault among these memory banks is a repeating fault, then the fault type of that DIMM is determined to be a mixed repeating fault. Mixed repeating faults are more severe than simple repeating faults.

[0108] If there is one faulty memory bank in the entire DIMM, and the most severe fault in these memory banks is a row fault or column fault, then the fault type of the DIMM is determined to be a simple row-column fault, which is more severe than a mixed repetitive fault.

[0109] If multiple memory banks in a DIM have faults, and the most severe fault among these memory banks is a row fault or a column fault, then the fault type of the DIM is determined to be a mixed row-column fault. Mixed row-column faults are more severe than simple row-column faults.

[0110] If only one memory bank in the entire DIM has a fault, and the fault type of that memory bank is a severe row fault / severe column fault, then the fault type of that DIM is determined to be a single severe row / column fault. A single severe row / column fault is more severe than a mixed row / column fault.

[0111] If multiple memory banks in the entire DIMM have faults, and the most severe fault among these memory banks is a severe row fault or a severe column fault, then the fault type of the DIMM is determined to be a mixed severe row-column fault. A mixed severe row-column fault is more severe than a single severe row-column fault.

[0112] If only one memory bank in the entire DIMM is faulty, and the fault type of that memory bank is a critical fault, then the fault type of that DIMM is determined to be a single critical fault. A single critical fault is more severe than a mixed critical row-column fault.

[0113] If multiple memory banks in the entire DIMM have faults, and the most severe fault among these memory banks is a critical fault, then the fault type of the DIMM is determined to be a mixed critical fault, which is more severe than a single critical fault.

[0114] After identifying a hard fault, it needs to be addressed to prevent it from affecting the normal operation of the system.

[0115] For handling hard faults, memory fault isolation is generally used to avoid affecting the normal operation of the operating system. Of course, there are other ways to handle memory cells or pages with hard faults; this manual only uses memory isolation as an example.

[0116] For memory fault isolation, only the memory cells experiencing hard faults can be isolated. However, considering the existence of the existing kernel-provided fault isolation interface, page offline, this interface can be used to isolate memory pages with more severe faults based on the faults of the memory cells included in each memory page.

[0117] The following section will describe in detail one of the memory fault isolation methods described in this manual, such as... Figure 3 As shown, Figure 3 This is a flowchart illustrating a memory fault isolation method according to an exemplary embodiment, comprising the following steps:

[0118] Step 301: Determine the fault result of each memory unit according to the memory fault identification method described above.

[0119] The result type of each memory unit is used to characterize whether a hard fault exists in that memory unit.

[0120] In other words, based on the aforementioned memory fault identification method, memory cells with hard faults can be identified, thereby further isolating the faults.

[0121] Step 303: Determine the faulty memory page based on the fault results of the memory cells corresponding to each memory page.

[0122] Among them, the probability that the fault in the faulty memory page causes an uncorrectable error UE is greater than the probability threshold.

[0123] Specifically, for a single memory cell, the more times a CE (Complete Error) is repeatedly reported, the more serious its impact on system operation. Therefore, it is necessary to determine the severity of its impact on system operation based on the number of times a memory cell experiences a CE.

[0124] Furthermore, considering that a memory page is a memory page allocated by the operating system, two memory units with consecutive addresses in a memory page may not be physically contiguous in the memory module. Therefore, the faulty memory page can be determined based on the physical distribution of the faulty memory units.

[0125] For example, in some cases, two memory pages may have the same number of memory cells with hard faults, but the memory cells with hard faults in one memory page may be concentrated in a few memory banks, while the memory cells with hard faults in the other memory page may be scattered across multiple memory banks. In this case, the two types of memory pages may cause different degrees of failure in the UE, so it is necessary to determine the faulty memory page based on the fault type of the memory bank.

[0126] Furthermore, not every memory cell within a memory page that experiences a fault needs to be isolated. Since memory faults are isolated on a page-by-page basis, it's important to consider that if only one memory cell within a page has a hard fault, its impact on system operation is minimal. Isolating the entire page would waste memory space and reduce available memory. Therefore, only memory pages that significantly impact operating system performance should be isolated. These could be pages more likely to cause UE (User Experience Deficit) issues or those that may frequently trigger CE (Complete Error Detection).

[0127] The specific method for determining faulty memory pages based on the type of memory library fault can be configured according to the actual situation. For example, if an application has a low tolerance for memory faults, then memory pages related to the faulty row or column can be isolated if row or column faults exist in the memory library. If an application has a high tolerance for memory faults, then related memory pages can be isolated only if the faults in the memory library are more severe. This manual does not limit the method for determining faulty memory pages; any faulty memory page whose probability of causing a user experience (UE) to occur is greater than a probability threshold can be used as a method for determining faulty memory pages in this manual.

[0128] Step 305: Isolate the faulty memory page.

[0129] It's important to clarify that isolating a memory page means taking that memory page offline via the page offline interface, preventing the operating system from using it and isolating it from available memory pages. Specifically, the operating system stores an accessible page table that records the pages the operating system can access. When a memory page is taken offline, it is either removed from the accessible page table or marked as a bad page, preventing the operating system from accessing it.

[0130] Furthermore, considering that page offline will fail if the process is using the memory page that needs to be offline, in order to ensure that page offline succeeds, page offline can be executed repeatedly in case of failure, until the memory page that needs to be offline is successfully offline.

[0131] In other words, step 305 includes: calling a preset isolated memory page interface to isolate the faulty memory page; if isolating the faulty memory page fails, repeatedly executing the following steps until the faulty memory page is successfully isolated: if a specified period is reached, calling the preset isolated memory page interface to isolate the faulty memory page.

[0132] The above method isolates memory pages that have a greater impact on system operation, ensuring a sufficient supply of available memory pages. Simultaneously, it isolates severely faulty memory pages, preventing any impact on system efficiency. It should be noted that while the method described in this specification requires storing a fault database, for cloud computing scenarios, it is more crucial for the accuracy and coverage of memory fault identification. Therefore, although the above method requires a fault database compared to related technologies, it effectively solves the problems encountered in the cloud computing field mentioned above, making it worthwhile for cloud computing scenarios.

[0133] After describing the two methods provided in this manual, it is also necessary to explain the entity that performs these methods. The methods described above can be run on a standalone machine or applied to a central device that manages multiple electronic devices.

[0134] Specifically, in scenarios involving multiple electronic devices and a central device managing those devices, to make hard fault identification or memory isolation faster and more efficient (if remote communication is required and other remote devices determine the hard fault, it will be slower), the two methods mentioned above, or any one of them, can be applied to a single electronic device to identify memory cells with hard faults on that electronic device and / or to take memory pages offline on that electronic device.

[0135] Furthermore, if an electronic device malfunctions during operation and loses its stored fault database, the accuracy of hard fault identification may be affected. Therefore, to improve the coverage of hard fault identification, either of the two methods described above or any one of the two methods can be executed through a central device.

[0136] It should be noted that if the central device executes the above two methods, then the fault database stores fault records at the memory unit level for the entire lifecycle of multiple devices managed by the central device. Updating the fault database in step 201 is performed based on obtaining CE reports from each device. Step 305, isolating the memory page, involves issuing an instruction to the corresponding electronic device to isolate the memory page, and the memory page then executes the above methods.

[0137] In other words, this specification also provides a memory fault isolation system, which includes several servers and a central device for managing the servers. In the event of a CE (Memory Fault Isolation) error, the servers report the CE to the central device. The central device is at least used to identify memory cells with hard faults using the aforementioned memory fault identification method, or to determine memory pages that need to be isolated using the aforementioned memory fault isolation method, and to notify the servers to isolate the memory pages.

[0138] Furthermore, the above methods can be operated jointly by central equipment and individual machines to achieve better fault isolation.

[0139] The memory fault identification method and memory fault isolation method provided in this specification will be described in detail below through a specific embodiment.

[0140] This method is applied to central devices that manage multiple servers, such as Figure 4AAs shown, each server has an error data parsing component and a fault isolation execution component, while the central device has a fault type calculation component, a fault database, and a fault isolation scheduling component. The functions of each component are as follows.

[0141] Error data parsing component 401 is responsible for listening to error data reported by the service based on in-band and out-of-band (partial) data, parsing the original logs and register data in memory faults, and sending the fault data to the central device in a unified structured format to facilitate the calculation of error patterns.

[0142] In this context, "in-band" refers to CE data uploaded through the operating system, while "out-of-band" refers to CE data uploaded through the Baseboard Management Controller (BMC). Since CE data may be uploaded through either the operating system or the BMC, it is necessary to monitor the CE data reported by both.

[0143] In memory faults, the original log and register data are both CE data, which are different from each other. Therefore, it is necessary to combine the data from both to output fault data.

[0144] The raw log and register data can be obtained through edac or mcelog. The output fault data in a standardized format should include at least the space information of the memory cell corresponding to the fault eccentricity (CE) and the impact range of the CE.

[0145] The fault type calculation component 411 receives the CE records uploaded by the error data parsing component, updates the fault database 413 on the central device, and determines whether a hard fault exists in the memory unit where the CE occurred based on all fault data since the server went online. Based on the fault records of each memory unit, it determines the fault type of each memory bank, thereby determining the fault distribution, the scope of the fault's impact, etc. After determining the fault type of each memory bank, it also updates the fault type of that memory bank in the fault database 413.

[0146] The fault isolation scheduling component 412 has three functions. First, it determines the fault type of the memory page based on the fault type of each memory unit contained in the memory page, thereby determining the memory pages that need to be isolated.

[0147] Secondly, it is responsible for scheduling page offline operations, that is, issuing page offline instructions to the server. Furthermore, considering that kernel page offline is a try-best operation and cannot completely guarantee the isolation of a page, the scheduler is specifically designed to support event-triggered and timed cyclical scheduling strategies. Internally, the component triggers isolation based on the fault type of the memory page stored in the fault database. When isolation fails, the reason for the failure is determined, and the isolation operation is rescheduled at an appropriate time. If isolation is successful, the isolation status of the memory page can be recorded in fault database 413. Additionally, when the server restarts and comes back online, previously isolated memory pages can be isolated again.

[0148] Third, maintain the fault database. For example, after a memory module is repaired, the fault data corresponding to that memory module needs to be cleared from the fault database.

[0149] The fault database 413 is used to record fault records throughout the entire lifecycle of each memory unit. The fault records may include the number of CE occurrences, fault data output by 401, fault type of memory unit, number of memory units of each fault type included in each memory page, and isolation status of memory page, etc.

[0150] Finally, the fault isolation execution component 402 is used to call the kernel's page offline interface to isolate memory pages when it receives a page offline instruction from the server; and to report the reason for the isolation failure to the server when the memory isolation fails; and to report a message of successful isolation to the server when the isolation is successful.

[0151] It should also be noted that different components within the same device can be executed in parallel or in sequence. The components are separated in this specification for the convenience of explaining how each step is executed, and this does not imply any limitation on the components in this specification.

[0152] After describing the methods shown in this specification through the functional descriptions of multiple components, the two methods shown in this specification will be described in detail below by processing the remaining information.

[0153] The interaction between any server and the central device, such as Figure 4B As shown:

[0154] Step 431: The server parses the original fault data, outputs formatted fault data, and sends it to the central device.

[0155] Step 441: After receiving the reported fault data, the central device determines the fault type of the memory unit corresponding to the fault data and updates the fault data, the number of CEs of the memory unit, and the fault type to the fault database.

[0156] Step 442: For each memory page, the central device determines whether the memory fault isolation criteria are met. If they are met, the isolation task is added to the fault isolation scheduling queue.

[0157] Step 443: The central device sends a page offline command to the server according to the fault isolation scheduling queue.

[0158] Step 432: The server calls the kernel's page offline interface according to the instruction sent by the central device to take the corresponding memory page offline.

[0159] Step 433: The server sends the result and reason (reason for failure) of the successful or failed offline process back to the central device.

[0160] Step 444: If the central device is successfully taken offline, update the offline status of the corresponding memory page in the fault database. If the offline task fails, add the offline task back to the fault isolation scheduling queue.

[0161] Corresponding to the embodiments of the aforementioned methods, this specification also provides an embodiment of a memory fault identification device, a memory fault isolation device, and an electronic device to which the same is applied.

[0162] like Figure 5 As shown, Figure 5 This is a block diagram illustrating a memory fault identification device according to an exemplary embodiment of this specification. A fault database is pre-configured, recording fault records for the entire lifecycle of all memory units. Each memory unit fault record includes at least the number of CE (Complete Error Correction) events occurring during the entire lifecycle of that memory unit. The device includes:

[0163] The fault database update module 510 is used to update the fault database in the event of a correctable error (CE) in a memory cell.

[0164] The memory fault identification module 520 is used to determine that there is a hard fault in each memory cell if the number of CE occurrences in the entire life cycle of the memory cell exceeds a threshold in the fault database.

[0165] Specifically, the fault database update module 510 is used to: obtain the log file corresponding to the CE that occurred in the memory unit; parse the obtained log file and output a fault record in a predetermined format; the fault record in the predetermined format includes at least the address of the memory unit where the CE occurred; store the fault record in the predetermined format in the fault database and update the number of times the corresponding memory unit CE occurred in the fault database.

[0166] The device may further include a memory bank fault type determination module 530 (not shown in the figure), which is used to determine the fault type of each memory bank based on the fault records of the memory units in the memory bank throughout their entire life cycle and the physical location relationship of each memory unit in the fault database; the fault type of the memory bank is used to characterize the severity of the memory bank fault.

[0167] Specifically, the memory library fault type determination module 530 is used to: determine the fault type of the memory library as a repeated fault if the number of memory cells that have experienced a Completely Executed Error (CE) in the memory library is less than a first threshold value, and at least one memory cell that has experienced a CE has a hard fault; determine the fault type of the memory library as a row or column fault if a fault row or column exists in the memory library; determine the fault type of the memory library as a row or column fault if the number of memory cells that have experienced a CE in the fault row or column is greater than or equal to the first threshold value, and there is no hard fault in the fault row or column; determine the fault type of the memory library as a severe row or column fault if a severe fault row or column exists in the memory library, and the number of severe fault rows and / or severe fault columns is less than a second threshold value; determine the fault type of the memory library as a severe row or column fault if the number of memory cells that have experienced a CE in the severe fault row or column is greater than or equal to the first threshold value, and at least one memory cell in the severe fault row or column has a hard fault. A fault is defined as a serious fault in a memory bank if the number of memory cells that have experienced a Complete Execution (CE) is greater than a third threshold and the total number of rows and columns that have experienced a CE is greater than a fourth threshold. The third threshold is greater than the first threshold, and the fourth threshold is greater than the second threshold.

[0168] In addition to the memory bank fault type determination module 530, the device may also include a DIMM fault type determination module 540 (not shown in the figure). This module is used to: determine the fault type of each dual in-line memory module (DIMM) based on the fault types of each memory bank contained in the DIMM; the fault type of the DIMM is used to characterize the severity of the DIMM fault.

[0169] like Figure 6 As shown, Figure 6 This is a block diagram illustrating a memory fault isolation device according to an exemplary embodiment, comprising:

[0170] The fault result determination module 610 is used to determine the fault result of each memory unit according to the memory fault identification method described above; the result type of each memory unit is used to characterize whether there is a hard fault in each memory unit.

[0171] The faulty memory page determination module 620 is used to determine the faulty memory page based on the fault results of the memory cells corresponding to each memory page; wherein, the probability that the faulty memory page causes an uncorrectable error UE is greater than a probability threshold.

[0172] Memory page isolation module 630 isolates the faulty memory page.

[0173] Specifically, the memory page isolation module 630 is used to call a preset isolation memory page interface to isolate the faulty memory page; if the isolation of the faulty memory page fails, the following steps are executed repeatedly until the faulty memory page is successfully isolated: if a specified period is reached, the preset isolation memory page interface is called to isolate the faulty memory page.

[0174] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0175] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0176] like Figure 7 As shown, Figure 7 This diagram illustrates a hardware structure of an electronic device containing an embodiment of a memory fault identification device or memory fault isolation device. The device may include: a processor 1010, a memory 1020 for storing processor-executable instructions, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are internally connected to each other via the bus 1050.

[0177] The processor 1010 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to run the executable instructions to implement the memory fault identification method or memory fault isolation method described above.

[0178] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0179] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0180] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0181] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0182] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0183] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the memory fault identification method or memory fault isolation method described above.

[0184] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0185] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0186] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

Claims

1. A memory fault identification method, comprising pre-configuring a fault database, wherein the fault database records fault records for the entire lifecycle of all memory units, and each memory unit fault record includes at least the number of CE (Complete Error Correction) events occurring during the entire lifecycle of that memory unit; the method comprising: In the event of a correctable error (CE) in a memory cell, update the fault database; For each memory cell, if the number of CE (Complete Error) events occurring during the entire lifecycle of that memory cell in the fault database exceeds a certain threshold, then that memory cell is determined to have a hard fault. Among them, a number of memory units form a memory library. For each memory library, the fault type of the memory library is determined based on the fault records of the memory units throughout their entire life cycle and the physical location relationship of each memory unit in the fault database. The fault type of the memory library is used to characterize the severity of the memory library fault. If two memory pages have the same number of memory cells with hard faults, and the memory cells with hard faults in one memory page are concentrated in a few memory banks, while the memory cells with hard faults in the other memory page are scattered in multiple memory banks, then the faulty memory page is determined according to the fault type of the memory bank corresponding to the memory cell with hard faults in the memory page.

2. The method according to claim 1, wherein updating the fault database in the event of a correctable error (CE) in a memory cell comprises: Obtain the log file corresponding to the CE (Continuity Error) that occurred in the memory unit; The acquired log file is parsed, and fault records in a predefined format are output. The fault record in the predetermined format includes at least the address of the memory cell where the fault occurred; Fault records in a predetermined format are stored in the fault database, and the number of CE occurrences for the corresponding memory unit in the fault database is updated.

3. The method according to claim 1, wherein determining the fault type of the memory bank based on the fault records of the memory units throughout their entire lifecycle and the physical location relationships of each memory unit contained in the fault database includes: If the number of memory cells that have experienced a CE in the memory bank is less than a first threshold, and at least one memory cell that has experienced a CE has a hard fault, then the fault type of the memory bank is determined to be a recurring fault. If a faulty row or column exists in the memory bank, the fault type of the memory bank is determined to be a row or column fault; the number of memory cells that have experienced a CE in the faulty row or column is greater than or equal to a first quantity threshold, and there is no hard fault in the faulty row or column. If there is a critical fault row or column in the memory bank, and the number of critical fault rows and / or critical fault columns is less than a second quantity threshold, then the fault type of the memory bank is determined to be a critical row or column fault; the number of memory cells that have experienced a CE in the critical fault row or critical fault column is greater than or equal to a first quantity threshold, and at least one memory cell in the critical fault row or critical fault column has a hard fault. If the number of memory cells that have experienced a Complete Execution (CE) in the memory bank is greater than a third threshold, and the total number of rows and columns that have experienced a CE is greater than a fourth threshold, then the fault type of the memory bank is determined to be a serious fault; the third threshold is greater than the first threshold, and the fourth threshold is greater than the second threshold.

4. The method according to claim 1, further comprising: For each dual in-line memory module (DIMM), the fault type of the DIMM is determined based on the fault types of each memory bank contained in the DIMM; the fault type of the DIMM is used to characterize the severity of the DIMM fault.

5. A memory fault isolation method, the method comprising: The method according to any one of claims 1-4 determines the fault result of each memory cell; The result type of each memory unit is used to characterize whether a hard fault exists in that memory unit; Based on the fault results of the memory cells corresponding to each memory page, the faulty memory page is determined; wherein, the probability that the fault in the faulty memory page causes an uncorrectable UE error is greater than the probability threshold. Isolate the faulty memory page.

6. The method according to claim 5, wherein isolating the faulty memory page comprises: The faulty memory page is isolated by calling the preset isolation memory page interface; If isolating the faulty memory page fails, repeat the following steps until the faulty memory page is successfully isolated: When a specified period is reached, a preset isolated memory page interface is invoked to isolate the faulty memory page.

7. A memory fault identification device, pre-configured with a fault database, the fault database recording fault records for the entire lifecycle of all memory units, each memory unit fault record including at least the number of CE (Error Correction) events occurring during the entire lifecycle of that memory unit; the device comprises: The fault database update module is used to update the fault database when a correctable error (CE) occurs in a memory cell. The memory fault identification module is used to determine if a memory cell has a hard fault if the number of CE (Complete Error) events during the entire lifecycle of the memory cell exceeds a certain threshold in the fault database. The memory bank consists of several memory units. The memory fault identification module is also used to determine the fault type of each memory bank based on the fault records of the memory units throughout their entire lifecycle and the physical location relationship of each memory unit in the fault database. The fault type of the memory bank is used to characterize the severity of the memory bank fault. If two memory pages have the same number of memory units with hard faults, and the memory units with hard faults in one memory page are concentrated in a few memory banks, while the memory units with hard faults in the other memory page are scattered in multiple memory banks, then the faulty memory page is determined according to the fault type of the memory bank corresponding to the memory units with hard faults in the memory page.

8. A memory fault isolation device, the device comprising: A fault result determination module is used to determine the fault result of each memory unit according to the method described in any one of claims 1-4; The result type of each memory unit is used to characterize whether a hard fault exists in that memory unit; The faulty memory page determination module is used to determine the faulty memory page based on the fault results of the memory cells corresponding to each memory page; wherein, the probability that the faulty memory page causes an uncorrectable error UE is greater than a probability threshold. A memory page isolation module is used to isolate the faulty memory page.

9. A memory fault isolation system, the memory fault isolation system comprising a plurality of servers and a central device for managing the plurality of servers; In the event of a CE (Collapse Detection), the server will report the CE to the central device. The central device is at least used to identify memory cells with hard faults using the memory fault identification method according to any one of claims 1-4, or to determine memory pages that need to be isolated using the memory fault isolation method according to claim 5 or 6, and to notify the server to isolate the memory page.

10. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the memory fault identification method as described in any one of claims 1-4, or the memory fault isolation method as described in claim 5 or 6, by running the executable instructions.

11. A computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the memory fault identification method as described in any one of claims 1-4, or the memory fault isolation method as described in claim 5 or 6.

Images