Interconnection sharing method of ECC / CRC-free memory based on CXL protocol and computer system

Abstract

The application discloses a kind of interconnection sharing method and computer system of ECC / CRC-free memory based on CXL protocol, interconnection sharing method includes the following steps: error handling module collects error events and statistics times, generates error record table, obtains bad track area, establishes bad area table;The health level and load level of region are divided, and the health degree of memory is obtained, to obtain the candidate bucket of good area;When memory needs to be remapped, error handling module obtains the memory corresponding to the memory that needs to be remapped;According to the size of bad track area, select the matching candidate bucket, determine one or more target buckets;The address information corresponding to the candidate area in the target bucket is input into the bad area table, if the current candidate area is not hit, the current candidate area is selected as the target area;If the current candidate area is hit, replace the target bucket, until the candidate area of the bad area table is not hit, and is selected as the target area;Data in bad track area is moved to target area.

Description

Technical Field

[0001] Specifically, this invention relates to an interconnection and sharing method for ECC / CRC-free memory based on the CXL protocol and a computer system for executing the interconnection and sharing method. Background Technology

[0002] In existing server and high-performance computing systems, memory serves as a critical resource for data storage and operation, and its reliability and availability directly determine the overall stable operation of the system. However, as DRAM manufacturing processes continue to shrink and cell structures become more refined, the probability of physical defects such as bad sectors and weak cells generated during manufacturing increases significantly, leading to a decrease in finished product yield. Simultaneously, during long-term operation, due to factors such as electrical stress, temperature drift, and aging, memory cells may also experience permanent or intermittent errors, resulting in system anomalies or even crashes. Traditional memory error detection mainly relies on ECC and CRC modules integrated within the controller or chip for error correction and verification. By adding check bits or link checks, some random errors can be detected and corrected. However, such mechanisms require additional bit overhead and dedicated circuitry, making them only suitable for high-cost server-grade memory devices and difficult to promote in scenarios using large amounts of ordinary, non-ECC DRAM. Furthermore, even with ECC, it typically only corrects minor random errors repeatedly, making it difficult to actively mark and isolate repeatedly erroneous physical cells, and even less capable of cross-device physical address remapping and bad sector avoidance between different memory modules. For defective memory modules detected during the manufacturing process, existing technologies mostly handle them by directly scrapping them or coarsely shielding banks and channels, resulting in a large amount of remaining healthy capacity not being able to be finely mined and complemented. Although some controllers support limited row / column remap functions, they are still limited to a single chip or a single DIMM and cannot perform bad area compensation between multiple memory devices.

[0003] With the development of Compute Express Link (CXL) interconnect technology, host processors can access multiple independent memory devices in a consistent or semi-consistent manner, achieving unified addressing and dynamic mapping across physical modules. This provides a new hardware foundation for building shared memory pools at the system level and migrating logical regions across devices. However, existing systems have not fully utilized CXL's interconnect and programmable mapping capabilities. Without introducing additional ECC and CRC dedicated error correction hardware, it is difficult to achieve bad sector identification, cross-device address repair, and shared pooling reuse of degraded memory based on access anomalies, timeout behaviors, and upper-layer read / write consistency results. Therefore, how to build a bad sector management and capacity reuse method adapted to CXL memory shared pools under ECC / CRC conditions has become an urgent need to improve memory reliability and manufacturing yield.

[0004] Therefore, existing technologies still have significant technical pain points in handling bad sectors and defective areas in memory: First, most existing solutions are based on ECC / CRC, which can only detect and correct random or transient errors. They lack the ability to continuously manage repeated errors and gradual degradation of the same physical unit, making it difficult to proactively retire, mask, or migrate failed units in a timely manner. Second, traditional row / column remapping, page-level masking, and fuse repair mechanisms are usually limited to a single chip or a single memory module, with a limited repair scope. They cannot achieve cross-module or cross-channel bad sector remapping and capacity reorganization between different memory devices. Third, these repair mechanisms are highly dependent on the memory controller, BIOS firmware, or chip-built-in redundant resources, and their dynamic management capabilities are insufficient. Once the accumulated errors exceed the repairable range, they can often only be solved by coarse-grained methods such as powering down the entire module or replacing components. In addition, for defective or "edge" memory devices detected at the factory, the fuse repair of existing processes can only replace a very small number of bad rows / columns. Once the defects exceed the limit, they are directly scrapped or downgraded in a large granular manner, resulting in a large number of still healthy storage units being unable to participate in system construction, leading to significant resource waste and cost pressure.

[0005] For example, patent CN119088614A discloses a CXL memory module, a memory repair method, a control chip, a medium, and a system. This patent addresses memory modules with only one DDR controller, making it unsuitable for systems with multiple DDR devices, i.e., unsuitable for memory modules managed by multiple DDR controllers. Furthermore, ordinary switches typically use a master table lookup (in the uplink port) to directly allocate data to the target port based on the uplink port, which is slow.

[0006] Overall, existing technologies lack a mechanism that can combine error behavior and access characteristics to perform cross-device dynamic mapping and complementary utilization of defective modules among multiple CXL devices without relying on additional ECC / CRC hardware. This makes it difficult to improve reliability while also ensuring the utilization rate and cost control of large-scale memory pools.

[0007] The above background information is provided only to aid in understanding the inventive concept and technical solution of this invention. It does not necessarily belong to the prior art of this invention. In the absence of clear evidence that the above information was disclosed before the filing date of this invention, the above background information should not be used to evaluate the novelty and inventiveness of this invention. Summary of the Invention

[0008] In view of this, in order to overcome the shortcomings of the prior art, the purpose of this invention is to provide an interconnection and sharing method for ECC / CRC-free memory based on the CXL protocol.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] An interconnection and sharing method for ECC / CRC-free memory based on the CXL protocol, executed by a computer system, wherein the computer system includes a root component, a switch, and memory connected in sequence, wherein the root component is provided with a root port, the uplink port of the switch is connected to the root port, and the memory is connected to the downlink port of the switch, and the switch is provided with a manager and an error handling module, and the interconnection and sharing method includes the following steps:

[0011] The error handling module collects memory error events and counts the number of error events, while generating an error record table. Based on the address information in the error record table, it obtains bad sector regions and establishes a bad sector table.

[0012] The memory is divided into regions with different health levels and different load levels. The health of the memory is obtained based on the region health level, the load level, and the health of the memory. Candidate buckets for good regions are obtained based on the region health level, the load level, and the health of the memory.

[0013] When a memory error occurs and remapping is required, the error handling module obtains the corresponding memory that needs to be remapped based on the logical address region identifier corresponding to the bad sector region, the size of the bad sector region, and the timestamp.

[0014] Based on the size of the bad sector region, select matching candidate buckets, and add the health score corresponding to the region health level of the candidate region within the candidate bucket and the load score corresponding to the memory load level. Based on the added score, determine one or more candidate buckets as target buckets.

[0015] The manager inputs the address information corresponding to the candidate region in the target bucket into the bad region table. If the current candidate region is not matched, the current candidate region is selected as the target region. If the current candidate region is matched, the target bucket is changed until a candidate region that is not matched in the bad region table is obtained and selected as the target region.

[0016] The mapping table is updated based on the bad sector region and the target region of the memory that needs to be remapped, and the data in the bad sector region is moved to the target region.

[0017] According to some preferred embodiments of the present invention, the error event includes a data inconsistency error event: the root component verifies the data during data transmission, and when it finds that the data is inconsistent with the expected data, it generates a data inconsistency error event and records the corresponding target access address and device identifier.

[0018] According to some preferred embodiments of the present invention, the error event includes a response error event: after the root port initiates an access, if the access fails, a response error event is generated, and the target access address and device identifier corresponding to the access are recorded.

[0019] According to some preferred embodiments of the present invention, the error event includes a timeout / retry error event: the switch and its downlink port monitor the timing and retry behavior of the CXL channel. When the same address is detected to have a continuous timeout within a set time, the number of retries exceeds a threshold, or the process cannot be completed, the downlink port generates a timeout / retry error event and records the target access address and port information.

[0020] According to some preferred embodiments of the present invention, the error log table includes the following information: Device identifier: used to indicate the memory or downlink port involved in the corresponding error, determined by the root port or downlink port according to the target access address;

[0021] Address information: Used to mark the address regions that caused the error;

[0022] Error type: Used to distinguish the source and type of error;

[0023] Timestamp: Used to record when the error occurred.

[0024] According to some preferred embodiments of the present invention, obtaining bad sector regions based on address information in the error record table includes the following steps:

[0025] Convert the address information, which is in the form of a host physical address, to the corresponding device physical address; if the address information is directly the device physical address given by the root port or the downlink port of the switch, proceed to the next step;

[0026] By combining the address decoding rules of the memory where the error occurred, the device's physical address is mapped to the specific physical unit location where the error occurred;

[0027] When the statistical value of the number of errors occurring at the same physical unit location exceeds a preset threshold, the physical unit location is determined to be a bad sector area, and its corresponding device is identified. At the same time, the logical address area identifier containing the physical bad sector area is determined.

[0028] According to some preferred embodiments of the present invention, the load levels are divided according to the following steps: the remaining space of the port's retransmission buffer is used as the rule for classifying the device load levels. The larger the proportion of the remaining space of the retransmission buffer, the lower the load level, and the corresponding level is a load score, with lower load scores. For example, a remaining space proportion of 2 / 3 or more is defined as low load level L0, a remaining space proportion of 1 / 3-2 / 3 is defined as load level L1, and a remaining space proportion of 0-1 / 3 is defined as load level L2. The load score for low load level L0 is 0, the load score for load level L1 is 1, and the load score for load level L2 is 2.

[0029] According to some preferred embodiments of the present invention, the health levels of regions within the memory are classified according to the following steps: The number of errors for each physical address region is retrieved from the error record table. The more errors accumulated within a statistical period, the higher the health level of that region, and the corresponding level is a health score. For example, 0 errors is H0 (extremely healthy), 1-2 errors is H1 (slightly unstable), and ≥3 errors is H2 (high risk). The health score for health level H0 is 0, the health score for health level H1 is 1, and the health score for health level H2 is 2.

[0030] According to some preferred embodiments of the present invention, the region health level division within the memory further includes the following steps: if the neighboring region of the region is a bad sector region, then the health level of the region is increased, and the health score of the region is also increased. For example, if the original health level of a region is H0, but the health level of its neighboring region is H2, then after this step, the health level of the region will be raised to H1, and the corresponding health score will also increase accordingly.

[0031] According to some preferred embodiments of the present invention, the health of the memory is statistically classified based on the health level of each region within the memory. If the number of regions with the highest health level, i.e., high-risk regions, exceeds 3 / 4 of the total number of memory units, the memory is deemed unusable, and its health level is 0. Only regions with a health level not equal to 0 can become candidate addresses.

[0032] According to some preferred embodiments of the present invention, the step of determining the target bucket is as follows: calculating the total score of the health score and the load score corresponding to the candidate regions under the candidate bucket, and the candidate bucket with the lowest total score is the target bucket. When different regions have the same score, random selection is performed to determine one or more candidate buckets as the target bucket.

[0033] The present invention also provides a computer system for performing the interconnection and sharing method described above.

[0034] Due to the adoption of the above technical solutions, the advantages of this invention compared to the prior art are as follows: The interconnection and sharing method of ECC / CRC-free memory based on the CXL protocol of this invention can use switches to compensate for the hardware's ability to correct / locate errors when the hardware itself lacks its own functions, thus achieving more accurate positioning; at the same time, it can use the cooperation of switches to realize concise information integration of device storage space, thereby realizing storage space repair and interconnection without the device's own participation. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram of a memory system structure based on CXL interconnect and three types of error detection under the condition of no ECC / CRC in an embodiment of the present invention. Detailed Implementation

[0037] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0038] In existing server and high-performance computing systems, memory reliability directly impacts system stability and business continuity. Advanced DDR and some CXL memory products typically detect and correct storage errors by integrating error correction and verification logic such as ECC and CRC within the controller or chip. However, these solutions require additional bits and complex circuitry, making them suitable only for a few high-cost devices. They cannot be deployed on ordinary memory without ECC / CRC or consumer-grade DRAM, nor can they achieve cross-module bad sector avoidance and capacity reorganization among multiple independent memory devices. For defective memory modules with localized bad sectors detected at the manufacturing stage, existing technologies mostly handle them by directly scrapping them or simply masking the local addresses, resulting in a large amount of remaining healthy capacity being unable to be utilized. With the development of CXL interconnect technology, hosts can achieve unified addressing and flexible mapping among multiple independent memory devices. To provide new possibilities for bad sector identification based solely on access anomalies, timeout behaviors, and upper-layer read / write consistency results, and for migrating logical regions across devices within a shared pool, avoiding bad sectors, and integrating residual capacity without relying on ECC and CRC, it is necessary to propose a method and system for memory bad sector avoidance and capacity reuse across a CXL device shared pool. The device shared pool in this invention consists of multiple CXL memory devices without ECC / CRC repair and detection functions. This invention employs multiple error monitoring methods in synergy to locate erroneous memory locations, performs corresponding physical monitoring, and then performs address mapping.

[0039] The computer system of the present invention includes a root component, a switch, and memory connected in sequence. The root component has a root port. The uplink port of the switch is connected to the root port, and the memory is connected to the downlink port of the switch. The switch contains a manager and an error handling module. Based on the above computer system, the present invention provides a method for interconnecting and sharing ECC / CRC-free memory based on the CXL protocol, comprising the following steps:

[0040] 1) The error handling module collects memory error events and counts the number of error events. At the same time, it generates an error record table, obtains bad sector regions based on the address information in the error record table, and establishes a bad sector table.

[0041] Error events include the following three types:

[0042] Error events include data inconsistency error events: the root component verifies the data during transmission, and when it finds that the data is inconsistent with the expected data, it generates a data inconsistency error event and records the corresponding target access address and device identifier.

[0043] Error events include response error events: If an access attempt is made after the root port fails, a response error event is generated, and the target access address and device identifier corresponding to the access are recorded.

[0044] Error events include timeout / retry error events: The switch and its downlink ports monitor the timing and retry behavior of the CXL channel. When the same address is detected to have a continuous timeout within a set time, the number of retries exceeds the threshold, or the process cannot be completed, the downlink port generates a timeout / retry error event and records the target access address and port information.

[0045] Preferably, the error log table includes the following information: Device identifier: used to indicate the memory or downlink port involved in the corresponding error, determined by the root port or downlink port based on the target access address;

[0046] Address information: Used to mark the address regions that caused the error;

[0047] Error type: Used to distinguish the source and type of error;

[0048] Timestamp: Used to record when the error occurred.

[0049] Preferably, obtaining the bad sector region based on the address information in the error record table includes the following steps:

[0050] Convert the address information, which is in the form of a host physical address, to the corresponding device physical address; if the address information is directly the device physical address given by the root port or the downlink port of the switch, proceed to the next step;

[0051] By combining the address decoding rules of the memory where the error occurred, the device's physical address is mapped to the specific physical unit location where the error occurred;

[0052] When the statistical value of the number of errors occurring at the same physical unit location exceeds a preset threshold, the physical unit location is determined to be a bad sector area, and its corresponding device is identified. At the same time, the logical address area identifier containing the physical bad sector area is determined.

[0053] 2) Divide the memory into regions with different health levels and memory with different load levels. Obtain the health of the memory based on the region health level, the load level, and the health of the memory. Then, obtain candidate buckets for good regions based on the region health level, the load level, and the health of the memory.

[0054] Preferably, the load level is divided according to the following steps: the remaining space of the port's retransmission buffer is used as the rule for classifying the device load level. The larger the remaining space of the retransmission buffer, the lower the load level, and the corresponding level is the load score, with lower load scores indicating lower load levels. For example, a remaining space ratio of 2 / 3 or more is defined as low load level L0, a remaining space ratio of 1 / 3-2 / 3 is defined as load level L1, and a remaining space ratio of 0-1 / 3 is defined as load level L2. The load score for low load level L0 is 0, the load score for load level L1 is 1, and the load score for load level L2 is 2.

[0055] Preferably, the health level of memory regions is determined as follows: The number of errors for each physical address region is retrieved from the error log table. The higher the cumulative number of errors within a statistical period, the higher the health level of that region, and the corresponding level is the health score. For example, 0 errors corresponds to H0 (extremely healthy), 1-2 errors to H1 (slightly unstable), and ≥3 errors to H2 (high risk). The health score for health level H0 is 0, for health level H1 it is 1, and for health level H2 it is 2.

[0056] Preferably, the internal memory region health level classification further includes the following steps: if the adjacent region of a region is a bad sector region, then the health level of that region is increased, and the health score of that region is also increased. For example, if a region's original health level is H0, but because the health level of its adjacent region is H2, then after this step, the health level of that region will be raised to H1, and the corresponding health score will also increase accordingly. In this invention, the level and score are understood from the magnitude of the numbers; the larger the value of the number, the higher the corresponding level and score, and the smaller the value of the number, the lower the corresponding level and score.

[0057] Preferably, the health of the memory is statistically classified based on the health level of each region within the memory. If the number of regions with the highest health level (i.e., high-risk regions) exceeds 3 / 4 of the total number of memory units, the memory is considered unusable, and its health level is 0. Only regions with a health level of not 0 can become candidate addresses.

[0058] 3) When a memory error occurs and remapping is required, the error handling module obtains the memory that needs to be remapped based on the logical address region identifier corresponding to the bad sector region, the size of the bad sector region, and the timestamp.

[0059] 4) Select matching candidate buckets based on the size of the bad sector region, and add the health score corresponding to the regional health level of the candidate region in the candidate bucket and the load score corresponding to the memory load level. Determine one or more candidate buckets as target buckets based on the added score.

[0060] The steps for determining the target bucket are as follows: calculate the total score of the health score and load score corresponding to the candidate regions under the candidate bucket, and the candidate bucket with the lowest total score is the target bucket. When different regions have the same score, random selection is performed to determine one or more candidate buckets as the target bucket.

[0061] 5) The manager inputs the address information corresponding to the candidate region in the target bucket into the bad region table. If the current candidate region is not hit, the current candidate region is selected as the target region; if the current candidate region is hit, the target bucket is changed until a candidate region that is not hit in the bad region table is obtained and selected as the target region.

[0062] 6) Update the mapping table based on the bad sector region and target region of the memory that needs to be remapped, and move the data in the bad sector region to the target region.

[0063] Implementation Example: This embodiment constructs a computer system based on the CXL protocol, interconnecting and sharing multiple ECC / CRC-free memory devices in a shared pool. The overall structure of the computer system includes a Root Complex, a CXL Switch, and multiple memory devices SDRAM0 to SDRAM3 (Memory 0 to Memory 3) connected via CXL channels. The Root Complex has a CXL Root Port. The CXL Switch has one uplink port (USP) and multiple downlink ports (DSPs). The uplink port of the switch is connected to the root port, and the downlink ports of the switch are connected to the memory devices. Figure 1As shown. The root component initiates CXL.mem access and establishes a CXL.mem channel with the downstream CXL switch through the CXL root port. The CXL switch integrates an HDM Decoder on the USP side, which decodes the access request based on the target access address of the CXL.mem from the host side and forwards it to the corresponding downlink port. Each downlink port is connected to multiple memory devices through the CXL channel. Each memory device is equipped with an HDM Decoder and an SDRAM storage array without ECC / CRC to provide actual data access capabilities. The host side (Root Complex) accesses multiple CXL memory devices without ECC / CRC through the CXL root port and the downstream CXL switch, treating multiple memory devices as a logical memory pool. In this architecture, the system identifies and locates errors at three levels: the host side discovers content errors through data comparison, the root port identifies memory access anomalies based on the access return status, and the switch / channel side discovers link or memory device anomalies through timeout and repeated retry behaviors. All these error-aware entry points work together to serve subsequent bad sector location and cross-device remapping, providing a foundation for "bad sector management and capacity reuse in CXL shared pools without ECC".

[0064] Specifically, in this embodiment, without setting ECC and CRC in memory, three error detection locations are set in the system architecture to detect access anomalies and generate error events from different levels:

[0065] 1. First error detection point – Error detection in host-side data comparison:

[0066] The host side (root component) performs data consistency checks, comparing the read data with the expected data during write-read-back operations performed by applications or self-test programs. When data inconsistencies are detected, [the system]... Figure 1 The host uses "data comparison" to detect errors, generating a data inconsistency error event containing the device identifier and the target access address, and reporting it to the error handling module. A read initiated by the host involves first writing data into the shared pool, then reading the written data and comparing it to the expected data. If they are inconsistent, a data inconsistency error event is generated.

[0067] 2. Second error detection point – CXL root port access success / failure determination:

[0068] After initiating a CXL.mem access, the CXL root port determines whether the access was successful or failed based on the completion message status returned from downstream. When it receives an abnormal status indicating access failure, media error, or lack of support, it... Figure 1The system determines whether the access was successful or failed. The root port records the target access address, device identifier, and error type corresponding to this abnormal access, and sends them to the error handling module as a response error event.

[0069] 3. Third error detection point – CXL channel timeout and retry behavior:

[0070] On the CXL switch and its downstream port (DSP) side, access timing monitoring and retry counting logic is configured to detect whether access to a specific target address or path is in a state of prolonged timeout, repeated retries, or inability to complete. When access on a CXL channel is detected to exhibit timeout / repetition multiple times, in Figure 1 If the access behavior is as shown by timeout / retry multiple times, the downlink port will associate this abnormal behavior with the target access address and device identifier of the current access, forming a third type of timeout / retry error event reporting error handling module.

[0071] Through the above three levels of error detection points, this embodiment obtains access anomaly information from three dimensions—host data content, CXL.mem response status, and link timing behavior—without relying on any ECC / CRC error correction / verification. This information is then uniformly handed over to the error handling module for recording and statistics, which is used to complete subsequent bad sector identification, cross-device remapping, and capacity reuse.

[0072] In this embodiment, the three types of error detection results—errors detected by the host-side "data comparison," access failure determined by the CXL root port, and access timeout / repeated access detected by the downlink DSP port—are all reported as "failed addresses" with their corresponding target access addresses, and are aggregated in the system. These failed addresses serve two purposes: firstly, they are input into the bad region table as reference addresses to be avoided in subsequent mappings, marking physical regions that are prohibited from being reassigned in subsequent mappings; secondly, they are distributed to each downlink port, and combined with the load conditions of each port, the number and distribution of failures in different address regions are summarized to form port load and health statistics, corresponding to step two below. Based on the statistical results reported by each downlink port, the memory shared pool manager removes marked failed address regions (bad sector regions) from the global physical address space, organizes the remaining healthy addresses according to health level and port load, and forms a set of "effective addresses" available for allocation. This set is then fed back to the good region table. This allows the selection of new physical address regions when performing memory expansion or bad sector remapping, using the set of failed addresses as prohibited regions and the set of effective addresses provided by the memory shared pool as candidate target regions. This achieves the avoidance of failed addresses and the reference and utilization of healthy addresses without relying on ECC / CRC.

[0073] More specifically, the interconnection and sharing method for ECC / CRC-free memory based on the CXL protocol in this embodiment includes the following steps:

[0074] Step 1: Error event detection and bad sector location

[0075] Step 1.1, Error Event Detection

[0076] Without the need for ECC or CRC, the system monitors memory access anomalies through a multi-point error monitoring approach, including but not limited to the following three categories:

[0077] 1) Host data comparison error:

[0078] When the host performs a memory self-test, application-layer data verification, or write-readback operation, it verifies and compares the read data with the original written data. If the read data is found to be inconsistent with the expected data, a data inconsistency error event is generated, and the target access address, device identifier, and relevant context information of this access are recorded and reported to the error handling module.

[0079] 2) Root port response error:

[0080] After initiating a CXL.mem access, the CXL root port determines whether the access was successful based on the completion message status code returned by the downstream CXL device or CXL switch. When it receives a completion message indicating media access failure, lack of support, or other error status, the root port generates a response error event, reporting the target access address and device identifier corresponding to the access as error information to the error handling module.

[0081] 3) CXL channel timeout / retry exception:

[0082] The CXL switch and its downlink ports monitor the timing and retry behavior of the CXL channel. When an access to a certain address area is detected to have timed out continuously within a preset time, exceeded the threshold for the number of retries, or failed to complete, the downlink port generates a timeout / retry error event and reports it to the error handling module along with the target access address and port information of the current access.

[0083] The above three types of abnormal events are uniformly input into the error handling module as "error events", serving as the basis for subsequent error record generation and bad sector location.

[0084] Step 1.2, Error Log Generation

[0085] After collecting error events, the error handling module extracts key fields for each event and writes them to the error log table, including at least the following information:

[0086] Device ID: Used to indicate the CXL memory device or downlink port involved in this error. It can be determined by the root port or downlink port based on routing information (destination access address).

[0087] Address information (HPA / DPA): Used to mark the target access address region that caused the error. For errors caused by host data comparison, the host physical address (HPA) should be recorded first; for errors from the root port or downlink port, the device physical address (DPA) carried in the message or the address derived by the manager should be recorded.

[0088] Error Type: Used to distinguish the source and type of error, such as response error, access timeout / retry error, host data inconsistency error;

[0089] Timestamp: Used to record the time when the error occurred, facilitating subsequent clustering statistics and trend analysis by time window.

[0090] The above fields are written into the error record table according to a predetermined format such as {device identifier, address information, error type, timestamp}. Multiple records can be generated for the same physical address to facilitate statistical analysis of error frequency and time distribution in subsequent steps. All error records are accumulated sequentially as the raw data for locating bad sector areas.

[0091] Step 1.3: HDM Decoding and Bad Sector Location

[0092] The address information in the error log table is converted into a unified device physical address representation by the HDM decoding module and the memory device's internal address decoding module, and bad sector regions are located accordingly. Specifically:

[0093] First, based on the HDM (Host-managed Device Memory) decoding module of each CXL memory device, the address in the error record in the form of HPA (Host Physical Address) is converted into the DPA (Device Physical Address) of the corresponding device; and for the DPA address that has been directly given by the root port or the downlink port, that is, the actual physical address of the device space has been obtained, then proceed directly to the next step.

[0094] Secondly, by combining the address decoding rules of the target access device, the device physical address DPA is mapped to specific physical dimensions such as channel, rank, bank, and row to obtain the physical unit location where the error occurred.

[0095] Then, the error handling module performs clustering statistics on error records within a preset time window: when the number of errors detected in a certain DPA region or a certain bank / row exceeds a preset threshold, and the errors from multiple sources such as host comparison, root port response, and downlink port timeout are consistent, the region is determined to be a bad range (DPA bad range), and the corresponding target access device is identified as a defective device. At the same time, based on the global logical address mapping relationship, the Logical Region ID containing the physical bad range is determined.

[0096] Finally, the output {defective device, bad sector region, logical address region identifier} serves as the location result of the bad sector region, which is used to trigger subsequent shared pool address remapping and cross-device data migration processes.

[0097] Step Two: Health Statistics and Target Area Selection

[0098] Step 2.1, Classification of Equipment Load Levels

[0099] The shared pool manager periodically obtains the performance data of the CXL switch's uplink and downlink ports. It uses the percentage of remaining space in the retransmission buffer of the corresponding port as the load level classification for the device, thus obtaining the load level of the corresponding memory device. The retransmission buffer is an essential hardware buffer for each transmit port. If this buffer is full before transmission, data cannot be sent. The remaining space information of the retransmission buffer can be used as feedback on the corresponding load, and this information will always be fed back to the switch internally; otherwise, data cannot be sent. The percentage of remaining buffer space can be used as the load level classification. In this embodiment, a remaining space percentage of 2 / 3 or more is defined as low load level L0, a remaining space percentage of 1 / 3-2 / 3 is defined as load level L1, and a remaining space percentage of 0-1 / 3 is defined as load level L2.

[0100] In this embodiment, the load level is divided according to the remaining space of the retransmission buffer in the switch. The load score corresponds to the load level. That is, the less remaining space of the retransmission buffer, the higher the load score. For example, the load score of low load level L0 is 0, the load score of load level L1 is 1, and the load score of load level L2 is 2.

[0101] Step 2.2: Health information of memory regions and memory health status.

[0102] While obtaining the device load level, the shared pool manager combines the bad sector region location results output in step one to update the health status of each CXL memory device and its internal address region: on the one hand, it counts the number of errors and the distribution of bad sector regions for each memory device within a fixed statistical period to obtain the health status of the memory device; on the other hand, it divides the DPA regions inside the memory that are not marked as bad sectors (bad sector regions) into health levels (such as extremely healthy H0, healthy H1, weakly healthy H2) according to error frequency and proximity.

[0103] The step of "classifying the health level (H0 / H1 / H2) of the region according to error frequency and proximity" can be understood as scoring and classifying the region based on the number of errors and their spatial distribution, as shown in the following steps:

[0104] 1) Error Frequency Statistics: For the health level of a region, the system retrieves the number of errors for each physical address region (e.g., per 4MB or per bank) from the error record table. The more errors accumulated within a statistical period, the higher the health level and health score of that region. For example, 0 errors is H0 (extremely healthy), 1-2 errors is H1 (slightly unstable), and ≥3 errors is H2 (high risk). The health score for health level H0 is 0, for health level H1 it is 1, and for health level H2 it is 2.

[0105] 2) Determine spatial proximity: Check if bad sectors are concentrated in adjacent addresses. If adjacent rows, columns, or banks all have anomalies, it indicates that the area may be affected by the same hardware defect, and the overall health level can be upgraded by one level. For example, if an area's original health level is H0, but because the health level of its adjacent areas is H2, then after this step, the health level of the area will be upgraded to H1, and the corresponding health score will also increase accordingly. In this embodiment, the level and score are understood from the magnitude of the numbers; the larger the value of the number, the higher the corresponding level and score, and the smaller the value of the number, the lower the corresponding level and score.

[0106] 3) Generate a health mapping table: Taking into account the above two factors, assign a health level label (H0 / H1 / H2) to each DPA area and record and summarize it for future site selection, prioritizing H0 areas as the target areas for migration.

[0107] The health of memory is actually statistically classified based on the health level of each region within the memory device. In this embodiment, when the number of H2 regions with high-risk health levels exceeds 3 / 4 of the total number of banks (storage units), the device is considered extremely unhealthy. For example, if the device has 8 banks and the number of high-risk regions exceeds 6, the device's health level is considered to be 0, and it is considered completely unusable. The device port channel with the higher address can be directly replaced to achieve fast replacement. For the device health level, it is only necessary to record whether the device can continue to be used (health level is not 0), without the need for more detailed level classification.

[0108] Step 2.3: Maintenance of the Good Region Table and the Bad Region Table

[0109] After completing the health and load information updates, the shared pool manager maintains the updates in the Good Region table and the records in the Bad Region table, as follows:

[0110] For regions identified as bad sectors in step one, their high-order address information is written into the Bad Region table; retired banks / channels can also be registered in the same way. In this embodiment, the high-order address is information containing both the device address and the region address. This address does not contain the resolved detailed address information; only the address information from the highest levels, port number, and region bank number are needed.

[0111] For still usable healthy DPA regions, they are divided into buckets based on their device load level and region health level, i.e., bucketed by {region health level, device load level}. Each bucket maintains the {device identifier, region start address, storage space size, region health score, device load score} of a single region. This step yields a candidate bucket queue (indexable candidate regions and region sizes) and bad zone address management.

[0112] This embodiment does not use hash tables for address mapping. Instead, it utilizes updates to routing tables (good zone table and bad zone table) to perform address mapping. This saves address storage space and also solves the drawback of insufficient hash table space leading to fewer bad zones in the mapping process. Bad zone addresses are uniformly handled by the manager for recording and processing, while new mapped addresses are recorded by each mapped port. Since ports only recognize their own routing tables for routing, updating the addresses in the entire table tells them which port's memory device the new data is stored on. In other words, this embodiment uses the ports themselves for address selection, which is faster and works well with address mapping.

[0113] Step 2.4: Calculate the site selection seed

[0114] When the {Access Device, Bad Sector Region, Logical Address Region Identifier} output in Step 1 triggers (i.e., when the memory device connected to the switch is deemed invalid and unusable) shared pool remapping, the error handling module calculates the address seed seed = (Logical Address Region Identifier, Bad Sector Region Size, Timestamp) based on the Logical Address Region Identifier to be migrated, the size of the bad sector region, and the current timestamp. Here, the Logical Address Region Identifier is managed using the port routing table in the switch, which is a routing method that uses an identifier instead of an address (existing technology). The memory device whose address needs to be replaced can be found based on the port routing number.

[0115] Step 2.5: Select candidate regions and add them to the queue.

[0116] In step 2.3, the indexable candidate regions in the candidate buckets are first matched with the size of the addressing seed region based on the region information contained in the obtained buckets (the region size contained in the candidate bucket must be larger than the size of the bad sector region) and then scored and filtered. The scoring is based on the information obtained above (load level L and region health level H). Here, only the region is scored. Based on the obtained candidate bucket information, we first check whether the memory health is 0. Only if it is not 0 will we continue to judge the health of the region below it.

[0117] In this embodiment, instead of using weighted scoring to obtain the final mapping address, the load score corresponding to the load level (L) and the health score corresponding to the region health level (H) are directly added together to select candidate regions from one or more candidate buckets as the final mapping address. The mapping address is calculated based on the information of the candidate regions obtained from the buckets, with candidate buckets having lower total scores taking priority. At the same time, there will inevitably be cases where different buckets have the same score. In this case, the first few positions (e.g., the first five) of the candidate queue are randomly selected as new mapping address candidates, meaning multiple target buckets are placed in the queue to prepare for the final selection.

[0118] Step 2.6, Lightning protection testing of bad zones

[0119] For each selected candidate region, the manager inputs its high-order address information into the bad region table to perform a bad region proximity detection, determining whether the candidate region is close to a bad region:

[0120] If the bad region list is hit, it means that the candidate region is physically close to the known bad regions or has a high probability of error, and is therefore judged as an unsafe candidate; if it is not hit, the candidate region is considered to be relatively isolated from the bad regions and can be regarded as a healthy candidate region.

[0121] Step 2.7: Determine the target area

[0122] Once a candidate region passes the lightning protection detection in step 2.6, the error handling module determines that region as the final target region. Simultaneously, it marks the region as "occupied" in the good region table to prevent subsequent duplicate allocation. The output of step 2.7 is the healthy target address required for subsequent cross-device data migration and mapping updates.

[0123] Step 2.8, Rollback Strategy

[0124] If step 2.6 determines that the current candidate region is close to a bad region, a fallback strategy is implemented: the candidate queue continues to try subsequent target buckets in the queue; if all candidate regions corresponding to target buckets are deemed unsuitable, the manager can adjust the required combination of health level and port load level, such as from H0→H1, from L0→L1, etc., and reselect a new target bucket, repeating steps 2.5 to 2.6. By cyclically executing steps 2.5 to 2.8, a target region that meets health constraints and is far from bad regions is found, or, in extreme cases, an upper-layer alarm is triggered.

[0125] Step 3: Cross-device data migration and global mapping update

[0126] Step 3.1: Freeze the write operations to the logical region to be migrated.

[0127] Once the target healthy region is determined in step two, the error handling module first performs access control on the logical region containing the bad sector region, temporarily freezing its write requests. Specifically, it can take one of two methods: pausing read and write or temporarily setting the region to read-only. At the same time, it allows existing read requests to be completed within a controllable range to avoid data being overwritten while migrating, thereby ensuring the consistency of the data to be migrated.

[0128] Step 3.2: Perform cross-device data migration

[0129] After the logical region is frozen, the CXL replication engine is invoked to perform data migration between the physical region (bad sector region) of the original defective device Device A (where the bad sector region is located) and the physical region (target region) of the target device Device B. Specifically, this can be achieved by the host reading / writing data block by block through CXL.mem, or by using P2P transmission if supported by the switch or device, directly copying data between the two CXL devices. During the migration process, ECC / CRC error correction is not relied upon; only the integrity of the CXL protocol at the transport layer is guaranteed until all valid data in the bad sector region is copied to the target region.

[0130] Step 3.3, Update Mapping

[0131] After data migration is complete and passes the necessary consistency checks, the mapping relationship between logical addresses and physical addresses needs to be updated: the previously recorded {defective device, bad sector region} is modified to {target device, target region}. This global mapping table can be maintained by the shared pool manager and queried by the host or CXL mapping unit during address translation. After the mapping update is completed, all subsequent accesses to the bad sector region will be redirected to the target region of the target device.

[0132] Step 3.4: Mark the bad sector area as unavailable and remove it from the available list.

[0133] After completing the mapping update, the error handling module marks the bad sector area on the original defective device Device A as an unusable area: on the one hand, it writes {defective device, bad sector area} into the bad sector table as a reference for bad sectors that need to be permanently avoided during subsequent address selection; on the other hand, it removes the physical area from the free address list or allocable area list of the corresponding device to prevent it from being misused again during subsequent shared pool allocation.

[0134] Step 3.5: Unfreeze and restore normal access.

[0135] After step 3.4, the system unfreezes the write access to the logical region from step 3.1, allowing the region to accept normal read and write requests again. At this point, the host and upper-layer software still use the original logical addresses for access, while the address translation path automatically directs requests to {target device, target region} based on the updated mapping relationship, achieving transparent bad sector shielding and cross-device migration for users and applications. At this point, the physical region containing the bad sector is completely isolated, and logical capacity is provided by other healthy devices in the shared pool, completing the bad sector shielding process.

[0136] In existing technologies, handling bad sectors or errors in memory primarily relies on ECC / CRC error correction and local masking mechanisms integrated within the controller or chip. Specifically, DDR or some CXL memory controllers can automatically correct single-bit errors during reads using ECC check bits. When multi-bit errors or link CRC check failures are detected, the system log is reported or an interrupt is triggered via the RAS mechanism, allowing manual intervention by maintenance personnel or upper-layer software. However, when the same physical storage unit experiences multiple errors within a short period, ECC / CRC can only passively correct or report errors for each access, lacking a unified strategy for proactive retirement and fine-grained isolation of that unit. To mitigate the risks posed by persistent errors, some controllers or firmware introduce row / column remapping, page-level masking, and other methods to mark frequently erroneous physical rows, columns, or pages as unavailable. These areas are then removed from the allocatable space by the controller during the internal address decoding stage or by the operating system during the physical memory management stage, preventing subsequent accesses from falling into bad sectors. However, the above solutions typically only work within a single chip or memory module, representing localized repairs within a single device and failing to reorganize address spaces across different memory devices. Furthermore, for defective memory devices detected during factory testing, manufacturers generally rely on chip-level BIST self-testing and fuse repair to replace a small number of bad rows or columns. When the number of bad blocks exceeds internal redundancy capacity, the entire chip or module is directly deemed defective and scrapped, or downgraded for use by granularly masking the entire Bank, Rank, and channel. While these existing solutions alleviate the problem of localized defects in single devices to some extent, they rely on dedicated error correction hardware such as ECC / CRC, limiting the repair scope to within a single module. They cannot perform cross-module bad sector complementation and capacity reuse across multiple CXL devices, still exhibiting resource waste and a lack of collaborative management at the shared pool level.

[0137] Based on the above-mentioned technical problems, the present invention adopts the following main technical means:

[0138] 1. Error event statistics based on access behavior and consistency verification

[0139] Without ECC / CRC, by collecting CXL access anomalies, timeout / retry failures, and host read / write consistency verification results, an error record table is generated and maintained to provide basic data for subsequent bad sector determination.

[0140] 2. Bad sector location based on HDM address decoding

[0141] By utilizing the HDM mapping and internal DPA decoding rules of the CXL device, the erroneous address is converted into specific physical dimensions such as channel, bank, and row, and the bad sector region is identified through clustering statistics within the time window.

[0142] 3. Good and bad address management based on health and load levels

[0143] Construct and maintain a bad area table and a good area table. The former records bad areas and high-risk areas, while the latter stores candidate healthy areas in buckets according to health level and equipment load level, so as to realize rapid site selection and lightning protection based on health perception and load perception.

[0144] 4. Cross-device remapping and data migration based on CXL shared pool

[0145] After bad sectors are identified, healthy targets are selected from the shared pool, and cross-device data migration is completed via CXL.mem or P2P. The global logical address mapping table is updated to achieve bad sector avoidance and transparent redirection while keeping the logical address unchanged.

[0146] 5. Unified closed-loop mechanism for bad sector management and capacity reuse

[0147] At the system level, a unified bad sector management table and operation log are established, and error detection, bad sector location, target selection, data migration and mapping update are linked into a closed-loop process. Bad sectors are removed and healthy sectors are spliced ​​together for multiple CXL memory modules with local defects, so as to realize the shared pooling and reuse of defective memory.

[0148] Based on the above-mentioned technical means, this invention addresses the shortcomings of existing memory error management and defective product utilization, especially in scenarios that do not rely on ECC and CRC, and solves the following technical problems:

[0149] 1. The problem of difficulty in identifying and isolating persistent failure units without ECC / CRC.

[0150] When using a large number of ordinary DRAMs without ECC or even defective memory devices with localized defects, traditional solutions lack effective means to distinguish between occasional access anomalies and persistent bad sectors. They are unable to identify and mark frequent errors in the same physical region without bit-level error correction / verification information. This invention, through statistical and cluster analysis of CXL.mem access anomalies, timeout behaviors, and upper-layer read / write consistency results, combined with HDM address mapping, identifies frequently erroneous physical regions as bad sectors and includes them in bad sector management, thereby achieving effective isolation of persistently failing units.

[0151] 2. The problem that bad sectors in memory cannot be avoided and rebuilt across devices in a multi-device shared pool.

[0152] Existing row / column remapping or page-level masking mechanisms are mostly limited to a single chip or a single memory module. Once a local area fails, it can only perform coarse-grained masking within the local memory device and cannot migrate the logical address region to a healthy space on other physical devices. This invention utilizes the unified addressing and programmable mapping characteristics of CXL interconnect to maintain the global logical address to {device, physical address} mapping relationship at the shared pool level. When a bad sector occurs in a device, the corresponding logical region is remapped across devices to other healthy CXL memory devices in the pool, achieving true cross-module bad sector avoidance and address space reconstruction.

[0153] 3. The lack of dynamic bad zone management and self-healing capabilities during operation.

[0154] Existing bad sector handling methods largely rely on factory repair, static firmware configuration, or manual maintenance. They lack the ability to perform online migration and dynamic repair based on real-time error behavior during system operation. This often results in the need to take the entire module offline or replace hardware after errors accumulate. This invention builds a runtime bad sector management mechanism in the CXL shared pool manager, continuously collects error events and port load, dynamically updates the good / bad sector table, and automatically triggers cross-device data migration and mapping updates upon detecting a bad sector. This achieves online self-healing and improved reliability without interrupting the overall system operation.

[0155] 4. The problem of defective memory not being pooled and complemented during manufacturing and operation.

[0156] For memory devices with localized bad sectors detected during manufacturing, and modules that exhibit partial degradation during operation, existing technologies often resort to scrapping the entire module or performing large-scale degradation, resulting in a large number of still-healthy memory cells being left idle. This invention integrates multiple CXL memory devices with localized defects into a shared pool for management. Through health level classification, bad sector removal, and cross-device remapping, the scattered healthy regions in each device are organized into a contiguous logical address space. This enables complementary assembly and capacity reuse of defective memory, thereby improving overall usable capacity and manufacturing yield.

[0157] 5. The lack of a unified bad sector management mechanism that combines error behavior, port load, and pooling mapping.

[0158] In traditional technologies, error detection, bad sector statistics, address migration, and load balancing are implemented at different levels, lacking an integrated management framework for CXL shared pools and failing to simultaneously ensure reliability, performance, and resource utilization. This invention proposes a joint management mechanism based on error event statistics, HDM address decoding, good / bad sector tables, and port load awareness. This mechanism integrates bad sector identification, health grading, cross-device mapping, and data migration into a closed-loop process, enabling unified bad sector management and capacity reuse for large-scale CXL memory shared pools without ECC / CRC support. This effectively overcomes the shortcomings of existing technologies in cross-device dynamic mapping and complementary utilization of defective modules.

[0159] This invention is applicable to memory expansion and pooling management in large-scale server systems, data centers, and high-performance computing environments, especially suitable for scenarios that heavily utilize ordinary non-ECC DRAM and memory modules with localized bad sectors or edge defects. As memory capacity continues to increase and manufacturing processes shrink, localized defects and aging degradation will become increasingly common. Traditional approaches often only allow for coarse-grained removal of entire modules or shielding large areas of address space, resulting in the waste of a large number of still-healthy storage units. This invention, without adding ECC or CRC hardware, utilizes CXL interconnect and shared pool management to achieve bad sector identification based on access behavior, dynamic remapping across devices, and pooled reuse of defective memory. It can reorganize multiple memory devices with localized bad sectors into logically contiguous usable space, significantly improving usable capacity and manufacturing yield. In cost- and availability-sensitive scenarios such as cloud computing platforms and AI training clusters, this invention can also achieve target addressing combining health awareness and load awareness, prioritizing the migration of data to low-load, high-health CXL devices, maintaining overall performance and bandwidth balance while shielding bad sectors. For high-availability applications such as financial transactions, online services, and industrial control, this invention provides a transparent, automated, and online-executable memory self-healing method, enabling the system to complete migration and repair without power-down when a partial failure occurs, reducing maintenance costs and improving business continuity. At the same time, this solution is also applicable to future heterogeneous memory and hierarchical memory architectures, and can serve as a basic technology for general CXL memory pool bad sector management and resource complementarity utilization, with broad engineering application prospects and promotional value.

[0160] The above embodiments prepared by the method of the present invention are only for illustrating the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be construed as limiting the scope of protection of the present invention. All equivalent changes or modifications made in accordance with the spirit and essence of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A method for interconnecting and sharing ECC / CRC-free memory based on the CXL protocol, executed by a computer system, the computer system comprising a root component, a switch, and memory connected sequentially, wherein the root component is provided with a root port, the uplink port of the switch is connected to the root port, and the memory is connected to the downlink port of the switch, characterized in that, The switch is equipped with a manager and an error handling module, and the interconnection and sharing method includes the following steps: The error handling module collects memory error events and counts the number of error events, while generating an error record table. Based on the address information in the error record table, it obtains bad sector regions and establishes a bad sector table. The memory is divided into regions with different health levels and different load levels. The health of the memory is obtained based on the region health level, the load level, and the health of the memory. Candidate buckets for good regions are obtained based on the region health level, the load level, and the health of the memory. When a memory error occurs and remapping is required, the error handling module obtains the corresponding memory that needs to be remapped based on the logical address region identifier corresponding to the bad sector region, the size of the bad sector region, and the timestamp. Based on the size of the bad sector region, select matching candidate buckets, and add the health score corresponding to the region health level of the candidate region within the candidate bucket and the load score corresponding to the memory load level. Based on the added score, determine one or more candidate buckets as target buckets. The manager inputs the address information corresponding to the candidate regions in the target bucket into the bad region table. If the current candidate region is not matched, it is selected as the target region. If the current candidate region is matched, the target bucket is changed until a candidate region that is not matched in the bad region table is obtained and selected as the target region. Specifically, for each selected candidate region, the manager inputs its high-order address information into the bad region table to perform a bad region proximity detection to determine whether the candidate region is close to a bad region. If the bad region table matches, it means that the candidate region is physically close to a known bad region or has a high probability of error, and is therefore determined to be an unsafe candidate. If it does not match, the candidate region is considered to be relatively isolated from the bad region and can be regarded as a healthy candidate region. The mapping table is updated based on the bad sector region and the target region of the memory that needs to be remapped, and the data in the bad sector region is moved to the target region.

2. The interconnection and sharing method according to claim 1, characterized in that, The error events include data inconsistency error events: the root component verifies the data during data transmission, and when it finds that the data is inconsistent with the expected data, it generates a data inconsistency error event and records the corresponding target access address and device identifier.

3. The interconnection and sharing method according to claim 1, characterized in that, The error events include response error events: after the root port initiates an access, if the access fails, a response error event is generated, and the target access address and device identifier corresponding to the access are recorded.

4. The interconnection and sharing method according to claim 1, characterized in that, The error events include timeout / retry error events: the switch and its downlink port monitor the timing and retry behavior of the CXL channel. When the same address is detected to have a continuous timeout within a set time, the number of retries exceeds the threshold, or the process cannot be completed, the downlink port generates a timeout / retry error event and records the target access address and port information.

5. The interconnection and sharing method according to claim 1, characterized in that, The error log table includes the following information: Device identifier: used to indicate the memory or downlink port involved in the corresponding error, determined by the root port or downlink port based on the target access address; Address information: Used to mark the address regions that caused the error; Error type: Used to distinguish the source and type of error; Timestamp: Used to record when the error occurred.

6. The interconnection and sharing method according to claim 1, characterized in that, The bad sector region is obtained based on the address information in the error record table, including the following steps: Convert the address information, which is in the form of a host physical address, to the corresponding device physical address; if the address information is directly the device physical address given by the root port or the downlink port of the switch, proceed to the next step; By combining the address decoding rules of the memory where the error occurred, the device's physical address is mapped to the specific physical unit location where the error occurred; When the statistical value of the number of errors occurring at the same physical unit location exceeds a preset threshold, the physical unit location is determined to be a bad sector area, and its corresponding device is identified. At the same time, the logical address area identifier containing the physical bad sector area is determined.

7. The interconnection and sharing method according to claim 1, characterized in that, The load levels are divided according to the following steps: the remaining space of the port's retransmission buffer is used as the rule for classifying the device load levels. The larger the remaining space of the retransmission buffer, the lower the load level and the lower the corresponding load score.

8. The interconnection and sharing method according to claim 1, characterized in that, The health level of the memory region is divided according to the following steps: the number of errors for each physical address region is taken from the error record table. The more errors that occur in a statistical period, the higher the health level of the region and the higher the corresponding health score.

9. The interconnection and sharing method according to claim 1, characterized in that, The memory region health level classification also includes the following steps: if the adjacent region of the region is a bad sector region, then the health level of the region is increased, and the health score of the region is also increased.

10. The interconnection and sharing method according to claim 1, characterized in that, The health of the memory is statistically divided based on the health level of each region within the memory. If the number of regions with the highest health level exceeds 3 / 4 of the total number of memory units, the memory is considered unusable and its health level is 0.

11. The interconnection and sharing method according to claim 1, characterized in that, The steps for determining the target bucket are as follows: calculate the total score of the health score and load score corresponding to the candidate regions under the candidate bucket, and the candidate bucket with the lowest total score is the target bucket. When different regions have the same score, random selection is performed to determine one or more candidate buckets as the target bucket.

12. A computer system, characterized in that, Used to perform the interconnection and sharing method as described in any one of claims 1-11.

Images