Enterprise-level solid state disk access load balancing method

Abstract

The application relates to an enterprise-level solid state disk access load balancing method, belonging to the technical field of solid state disk access scheduling, and comprising the following steps: obtaining a plurality of access requests in an access scheduling queue, determining flash access resources corresponding to each request and an occupation state; when a first access request at the head of the queue cannot be issued due to required resources being occupied by a previous access request, determining a blocked resource according to a resource occupation relationship, selecting a second access request from subsequent requests, which does not have an intersection with the required resource and the blocked resource, does not have data access sequence dependence with the previous access request, and the required resource is not occupied, and preferentially issuing the second access request; and after the blocked resource is released, the first access request is issued again. Thus, the flash access resources that are not blocked can be used to execute the request meeting the condition, resource idleness caused by the head blocking is reduced, flash resource utilization and access parallelism are improved, the throughput and response performance under high-concurrency load are improved, and the access load balancing of the enterprise-level solid state disk is realized.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive access scheduling technology, specifically a load balancing method for enterprise-level solid-state drives. Background Technology

[0002] In existing technologies, enterprise-level solid-state drives (SSDs) typically need to handle a large number of concurrent read and write requests simultaneously. There is a strong resource contention between the access scheduling queue within the controller and flash memory access resources such as NAND flash channels, dies, and planes. When a flash memory access resource required by the first request in the queue is already occupied by a prior request, if the queue order is strictly followed to wait for the resource to be released, even if other flash memory access resources required by subsequent requests are idle, they may not be released in time due to the blocking effect of the first request, resulting in a head-of-queue blockage. As enterprise-level business workloads exhibit characteristics such as high concurrency, mixed read / write operations, and discrete access locations, this blockage can cause some flash memory resources to become idle, reduce parallelism, and increase request response latency and tail latency. Therefore, the access scheduling process needs to consider not only the order of request arrival but also the actual resource occupancy status and the data access order constraints between different requests.

[0003] Existing publicly available technologies have improved solid-state drive (SSD) load balancing at different levels. For example, Chinese patent application CN116185631A discloses a load balancing method for multi-core SSDs. This method calculates idle time by statistically analyzing the maximum task duration, total idle time, and maximum idle interval of each processing core within a cycle, and then allocates pending I / O tasks to target cores accordingly to improve task load distribution on the multi-core controller side. While this scheme can reduce I / O processing latency caused by busy processing cores, its scheduling target is primarily the controller processing cores. It focuses on the selection and allocation of processor computing power load, but does not address the continuous blocking relationship caused by the occupancy of underlying flash memory access resources in the access scheduling queue. Furthermore, it does not provide a mechanism to prioritize requests from the head of the queue that can utilize idle flash memory resources while maintaining data access order constraints.

[0004] Furthermore, Chinese patent application CN119292541A discloses a load coordination scheduling method and system for solid-state drives (SSDs). This method improves load balancing of multi-dimensional resources by collecting and predicting the load of the main controller data, and by implementing coordinated control over physical address allocation, cache scheduling, and multi-channel parallel transmission. This solution focuses on forming overall scheduling decisions based on load characteristic prediction and multi-objective optimization, which can improve resource utilization at a macro level. However, in the specific request-level access process, there are still technical requirements regarding how to identify blocking resources that prevent the first request from being sent, how to avoid resource and order conflicts between selected subsequent requests and blocked links or prior requests, and how to restore the original scheduling priority of the first request after the blockage is cleared. Therefore, it is necessary to provide an access load balancing method for enterprise-level SSD access scheduling queues that reorders requests based on actual flash memory resource occupancy relationships to reduce the limitation of internal parallelism caused by first-order blocking. Summary of the Invention

[0005] The purpose of this invention is to provide an access load balancing method for enterprise-level solid-state drives, thereby addressing some of the drawbacks and shortcomings pointed out in the background art.

[0006] The present invention adopts the following technical solution to solve the above-mentioned technical problems:

[0007] Multiple access requests in the access scheduling queue are obtained, and the flash memory access resources corresponding to each access request and their occupancy status are determined. When the first access request at the head of the access scheduling queue cannot be sent because the required flash memory access resources are occupied by a prior access request that has been sent but not yet completed, the blocking resource is determined according to the resource occupancy relationship between the first access request and the prior access request. From the access requests after the first access request, a second access request is selected whose required flash memory access resources do not intersect with the blocking resource, have no data access order dependency with the prior access request, and whose required flash memory access resources are not occupied. The second access request is sent before the first access request, and the first access request is sent after the blocking resource is unoccupied, so as to use the unoccupied flash memory access resources that do not intersect with the blocking resource to execute the access request, thereby achieving access load balancing.

[0008] Furthermore, following the flash memory access resources waiting for the first access request, the access requests occupying the corresponding flash memory access resources and the flash memory access resources that the access requests continue to wait for are traced level by level. The traced flash memory access resources are formed into a blocked resource set, and the access requests that do not intersect with the blocked resource set are selected from the access requests after the first access request as the second access request.

[0009] Furthermore, based on the occupancy status of flash memory access resources in adjacent execution phases of the candidate access request, a candidate access request that can use unoccupied flash memory access resources and releases the flash memory access resources shared with the first access request before the blocking resources are unoccupied is selected as the second access request.

[0010] Furthermore, when the first access request cannot be sent due to the blocking resource being occupied, the sending qualification obtained by the first access request according to the scheduling order of the access scheduling queue is determined as a scheduling opportunity, and the scheduling opportunity is transferred to the second access request; after the blocking resource is released, the scheduling opportunity is returned to the first access request, so that the first access request is sent before subsequent access requests that have not yet obtained a scheduling opportunity.

[0011] Furthermore, when determining the candidate access request, the resource switching relationship between one execution stage of the candidate access request and the adjacent subsequent execution stage is compared. The candidate access request that can obtain another unoccupied flash memory access resource without waiting for the resource to be released after the flash memory access resource occupied by the previous execution stage is given priority as the second access request, so as to reduce resource waiting between adjacent execution stages.

[0012] Furthermore, during the execution of the second access request, it is monitored whether the next execution phase of the second access request needs to re-occupy the flash memory access resources shared with the first access request; if so, the second access request is suspended from acquiring the shared flash memory access resources before entering the next execution phase, and after the blocked resources are unoccupied, the first access request first acquires the corresponding flash memory access resources, and then the second access request is allowed to acquire the corresponding flash memory access resources.

[0013] Furthermore, when multiple candidate access requests can use unoccupied flash memory access resources, the candidate access request that can release two or more different flash memory access resources after execution is preferentially determined as the second access request, and the released flash memory access resources are allocated to subsequent access requests that are in a waiting state and whose required flash memory access resources do not intersect with the blocked resources.

[0014] Furthermore, after the scheduling opportunity is transferred to the second access request, the second access request completes the execution phase in which it obtained the scheduling opportunity; when the blocked resource is released from occupation before the end of the execution phase, the scheduling opportunity is no longer passed to the next execution phase of the second access request, and the scheduling opportunity is returned to the first access request.

[0015] Furthermore, when multiple access requests cannot be sent due to the blocking resource being occupied, the multiple access requests are identified as access requests to be restored, and the scheduling order of each access request to be restored in the access scheduling queue is retained. After the blocking resource is released, scheduling opportunities are returned to the access requests to be restored in sequence according to the retained scheduling order, and access requests following the second access request are prohibited from obtaining the scheduling opportunities transferred by the access requests to be restored.

[0016] Furthermore, after the blocked resource is released from its occupancy, a scheduling opportunity is returned to each pending access request in the scheduling order. After each pending access request acquires the blocked resource, completes the access, and releases the blocked resource, a scheduling opportunity is returned to the next pending access request in the scheduling order, so that the pending access requests acquire the blocked resource one by one in the scheduling order.

[0017] This invention acquires multiple access requests from an access scheduling queue and determines the flash memory access resources corresponding to each request and their occupancy status. When the first access request at the head of the queue cannot be sent because the required resources are occupied by a prior access request, the blocking resource is determined based on the resource occupancy relationship between the two. Then, a second access request is selected from after the head of the queue, whose required flash memory access resources do not intersect with the blocking resource, have no data access order dependency with the prior access request, and whose required resources are not occupied. This allows the second access request to be sent before the first access request. Thus, without violating data access order constraints, previously idle flash memory access resources can be utilized, reducing the cascading impact of head-of-queue blocking on subsequent requests and improving the internal access parallelism and flash memory resource utilization of the solid-state drive.

[0018] Simultaneously, the first access request is issued only after the blocked resource is released, allowing the head request, which was temporarily blocked due to resource contention, to resume execution, thus balancing the scheduling order of access requests with resource utilization efficiency. Compared to the sequential scheduling method that simply waits for the resources required by the head request to be released, this invention can reduce the probability of overall queue stagnation caused by local resource occupation, shorten the waiting time of some access requests, improve access throughput and response performance under high concurrency loads, and thereby achieve balanced scheduling of enterprise-level solid-state drive access loads among available flash memory resources. Attached Figure Description

[0019] Figure 1 This is a flowchart of the enterprise-level solid-state drive access load balancing process of the present invention.

[0020] Figure 2 This is a diagram showing the tracing of blocked resource sets and resource occupancy status in Embodiment 1 of the present invention.

[0021] Figure 3This is a graph showing the available flash memory access resources and candidate access request filtering in Embodiment 1 of the present invention.

[0022] Figure 4 This is the candidate access request resource release evaluation and preliminary scheduling diagram in Embodiment 1 of the present invention.

[0023] Figure 5 This is a diagram illustrating the scheduling opportunity transfer and return process in Embodiment 2 of the present invention.

[0024] Figure 6 This is a timing diagram for determining the execution phase and the release of blocked resources in Embodiment 2 of the present invention.

[0025] Figure 7 This is a sequence diagram of the return of the scheduled access request to be restored in Embodiment 2 of the present invention. Detailed Implementation

[0026] As attached Figure 1 As shown, in this embodiment, the enterprise-grade solid-state drive (SSD) is configured with an access scheduling queue to store multiple access requests awaiting issuance. Access requests may include read requests, write requests, and other requests requiring access to the flash memory medium submitted by the host to the enterprise-grade SSD. The access scheduling queue records each access request according to the scheduling order determined after it enters the queue. "Issuance" as used herein refers to transitioning an access request from the waiting state in the access scheduling queue to the execution state and allocating the flash memory access resources required for the current execution of that access request. After obtaining multiple access requests from the access scheduling queue, the flash memory access resources required by each access request during execution are determined, and the occupancy status of the corresponding flash memory access resources is obtained. Flash memory access resources are used to support the execution of access requests and can be hardware or logical resources on the enterprise-grade SSD that need to be allocated and have an occupancy status during the execution of access requests. Different access requests may correspond to one or more flash memory access resources based on their access content and execution process.

[0027] Enterprise-grade SSD controllers can determine the flash memory resources required by an access request at each execution stage based on the access address, address mapping information, and access type. For each flash memory resource, the controller can record its current state (whether it is unoccupied or occupied). When a flash memory resource is allocated to a corresponding access request, the controller updates it to occupied; when the access request completes its use of the flash memory resource and releases it, the controller updates it to unoccupied. By determining the occupancy status of flash memory resources, it can be determined whether the corresponding flash memory resource is already occupied by other issued but not yet completed access requests, thus providing a basis for access request scheduling. If an access request requires multiple flash memory resources in the same execution stage, the access request can be issued when all corresponding flash memory resources meet the resource acquisition conditions required for the current execution, and the occupancy status of the corresponding flash memory resources can be recorded.

[0028] During access scheduling, the first access request at the head of the access scheduling queue is evaluated. If the flash memory access resources required by the first access request are already occupied by a previously issued but not yet completed access request, the first access request cannot be issued directly according to the current scheduling order. A previously issued access request, as referred to in this paper, is an access request that was issued before the currently evaluated access request and has not yet been completed, occupying the flash memory access resources required for the execution of the currently evaluated access request. In this case, based on the resource occupancy relationship between the first access request and the corresponding previously issued access request, the flash memory access resource causing the first access request to fail to be issued is determined, and this flash memory access resource is identified as a blocking resource. When multiple flash memory access resources simultaneously cause the first access request to fail to be issued, each corresponding flash memory access resource can be identified as a blocking resource. After identifying the blocking resource, access requests following the first access request are filtered. During the filtering process, the flash memory access resources required by each access request are determined, and it is determined whether there is an intersection between the required flash memory access resources and the blocking resources. It is also determined whether there is a data access order dependency between the corresponding access request and the previously issued access request, and whether the required flash memory access resources are in an unoccupied state. Data access order dependency refers to the relationship where changing the execution order of two access requests may affect the correctness, consistency, or predetermined access results of the corresponding data. This can be determined based on the logical address range, access type, and order attribute carried by the access requests. For example, if two access requests access at least partially the same logical address range, and there is a necessary read / write or write order relationship between the two requests, a data access order dependency can be determined. The access request whose required flash memory access resource does not intersect with the blocked resource, has no data access order dependency with the preceding access request, and whose required flash memory access resource is not occupied, is identified as the second access request. When multiple access requests meet the above conditions, the second access request can be determined according to the original scheduling order of each access request in the access scheduling queue, prioritizing the access request with the higher scheduling order. If no second access request meeting the above conditions is found, the first access request remains in a waiting state until the corresponding blocked resource is released, and then the first access request is issued according to its scheduling order.

[0029] After the second access request is identified, while the first access request continues to wait for the blocked resource to be released, the second access request is sent before the first access request. This allows the second access request to utilize currently unoccupied flash memory access resources that do not intersect with the blocked resource to perform the corresponding access operation. Therefore, even when the first access request cannot be sent due to the partial occupation of flash memory access resources, other flash memory access resources not restricted by the blocked resource can still be used to execute access requests that meet the conditions, reducing the situation where other flash memory access resources are waiting due to the blocking of the first access request. Once the blocked resource is released, the first access request is sent again, allowing it to obtain the necessary flash memory access resources and perform the corresponding access operation. Through this method, while maintaining the data access order requirements between access requests, unblocked flash memory access resources are scheduled and utilized, thereby improving the utilization rate of flash memory access resources and achieving access load balancing for enterprise-level solid-state drives.

[0030] In this embodiment, when a first access request cannot be sent because the flash memory access resource it is waiting for is occupied, the resource occupancy relationship related to that flash memory access resource is traced step by step, starting from the flash memory access resource currently being waited for by the first access request. To achieve step-by-step tracing, the correspondence between each occupied flash memory access resource and the access request occupying that flash memory access resource can be recorded, as well as whether each incomplete access request is currently waiting for other flash memory access resources and the flash memory access resources being waited for. Specifically, the access request occupying the flash memory access resource is first determined, and then it is determined whether the access request continues to wait for other flash memory access resources. When there are still flash memory access resources waiting for the access request, the access request occupying the corresponding flash memory access resource and the flash memory access resource that the access request continues to wait for are determined, and the tracing is performed step by step in the manner described above. When the tracing reaches the point where the corresponding access request is no longer waiting for other flash memory access resources, the tracing along the tracing path is stopped; when a previously recorded flash memory access resource or access request is encountered again during the tracing process, it is not traced repeatedly to avoid continuous repeated tracing when a resource occupancy relationship forms a cycle. This tracing process allows for the identification of multiple flash memory access resources associated with the waiting relationship of the first access request, which are then grouped into a blocked resource set. Therefore, the blocked resource set includes not only the flash memory access resources directly awaited by the first access request, but also those obtained by tracing further along the resource occupancy relationship, thus reflecting the scope of blocking caused by resource occupancy and waiting relationships. When using a blocked resource set, the determination of whether subsequent access requests are affected by blocking relationships is based on the blocked resource set; the release of blocked resources can be determined according to the specific scheduling process, specifically by releasing the blocked resources currently directly awaited by the first access request.

[0031] After determining the set of blocked resources, access requests following the first access request are filtered. For each access request, the flash access resources required for its execution are determined and compared with the set of blocked resources. When the flash access resources required by an access request do not intersect with the set of blocked resources, it indicates that the execution of this access request does not require the use of flash access resources involved in the current blocking relationship. Therefore, if this access request simultaneously satisfies the conditions of no data access order dependency and that the flash access resources required for current execution are not occupied, this access request can be identified as the second access request. By filtering subsequent access requests according to the set of blocked resources, the second access request can avoid using flash access resources that are in a blocking relationship again, enabling the second access request to perform the corresponding access operation using flash access resources that are not affected by the set of blocked resources, and reducing the possibility of resource waiting relationships continuing to expand.

[0032] In this embodiment, when determining the second access request from the access requests following the first access request, access requests that meet the scheduling conditions can be identified as candidate access requests. The occupancy status of flash memory access resources is then filtered based on the adjacent execution stages of the candidate access requests. Meeting the scheduling conditions includes at least the following: there is no data access order dependency between the candidate access request and the preceding access request that needs to maintain its order; and the flash memory access resources required by the current execution stage of the candidate access request can be obtained according to the corresponding filtering conditions. An execution stage refers to a segment of the execution process during which a corresponding flash memory access resource is used. When an access request needs to acquire and release different flash memory access resources sequentially during execution, it can be divided into multiple adjacent execution stages based on the acquisition and release order of the flash memory access resources. Specifically, the flash memory access resources currently available to the candidate access request are determined, and it is determined whether the corresponding flash memory access resources are in an unoccupied state. Simultaneously, based on the execution process of the candidate access request, it is determined whether it will occupy flash memory access resources shared with the first access request, and whether these shared flash memory access resources can be released before the blocking resources are unoccupied. Whether shared flash memory access resources can be released before the blocking resource is unoccupied can be determined based on the current execution stage of the candidate access request, the resource usage and release order of subsequent execution stages, and the current execution status of the prior access request occupying the blocking resource. If it cannot be determined that the shared flash memory access resource can be released before the blocking resource, this condition is not considered satisfied. When a candidate access request can use unoccupied flash memory access resources and can release the shared flash memory access resource with the first access request before the blocking resource is unoccupied, the corresponding candidate access request can be used as the second access request. Therefore, while the first access request is waiting for the blocking resource to be unoccupied, the second access request can utilize the available flash memory access resources to perform the corresponding access operation, while reducing the possibility that the second access request's continued occupation of the shared flash memory access resource will affect the resumption of the first access request's execution.

[0033] In determining candidate access requests, the resource switching relationship between one execution stage of a candidate access request and the adjacent subsequent execution stage can be compared. After the previous execution stage ends and releases the flash memory access resources it occupies, it is determined whether the other flash memory access resource required by the subsequent execution stage is in an unoccupied state. When a candidate access request can obtain the other flash memory access resource required by the subsequent execution stage without waiting for other access requests to release resources after the flash memory access resource occupied by the previous execution stage is released, this candidate access request can be prioritized as the second access request. Using the above resource switching method, candidate access requests can complete the continuous switching of flash memory access resources between adjacent execution stages, reducing resource waiting caused by the flash memory access resources required by the subsequent execution stage being in an occupied state. When multiple candidate access requests meet the same resource switching conditions, they can be selected according to the original scheduling order of each candidate access request in the access scheduling queue, so that the scheduling results have a definite order.

[0034] During the execution of the second access request, the flash memory access resources required for the subsequent execution phase of the second access request are monitored, and it is determined whether the subsequent execution phase needs to re-occupy the flash memory access resources shared with the first access request. When the subsequent execution phase needs to re-occupy the shared flash memory access resources, the second access request's acquisition of the shared flash memory access resources is suspended before entering the subsequent execution phase, and the current execution progress of the second access request is recorded. For flash memory access resources that the second access request no longer needs to use after the current execution phase ends, they are released according to the corresponding resource release relationship, and their occupancy status is updated. After the blocked resources are released, the first access request is allowed to acquire the corresponding flash memory access resources first, and then the second access request is allowed to acquire the corresponding flash memory access resources, thereby avoiding the second access request from re-occupying the flash memory access resources required for the first access request to resume execution during the execution process. When there are multiple candidate access requests that can use unoccupied flash memory access resources, they can be filtered according to the flash memory access resources that can be released after each candidate access request is executed. Candidate access requests that can release two or more different flash memory access resources after execution are given priority as the second access request. When multiple candidate access requests can release the same number of different flash memory access resources, a second access request can be determined according to the original scheduling order of the candidate access requests in the access scheduling queue. After the second access request completes execution and releases the corresponding flash memory access resource, the released flash memory access resource is allocated to subsequent access requests that are in a waiting state and whose required flash memory access resource does not intersect with the blocked resource. This allows subsequent access requests to continue to use the released flash memory access resource to perform their corresponding access operations, thereby reducing the waiting time of flash memory access resources and improving resource utilization during the access scheduling process.

[0035] In this embodiment, when a first access request cannot be issued according to the predetermined scheduling order in the access scheduling queue due to the blocked resource being occupied, the issuance qualification originally obtained by the first access request based on the scheduling order can be determined as a scheduling opportunity. A scheduling opportunity represents the issuance qualification of an access request according to the current scheduling order, and can be recorded through scheduling status information associated with the access request or the scheduling position in the access scheduling queue. At this time, the scheduling opportunity corresponding to the first access request is not directly canceled, but rather transferred to a second access request that meets the issuance conditions, allowing the second access request to execute first using this scheduling opportunity. When transferring a scheduling opportunity, the access request currently associated with the scheduling status information can be changed from the first access request to the second access request, while retaining the original scheduling order of the first access request and the source information of the scheduling opportunity, so as to determine the first access request that needs to return a scheduling opportunity after the blocked resource is unoccupied. By transferring scheduling opportunities, other executable access requests can continue to be processed while the first access request waits for the blocked resource to be unoccupied. Once the blocked resources are released, the scheduling opportunity previously transferred to the second access request is returned to the first access request. This allows the first access request to be eligible for scheduling before subsequent access requests that have not yet obtained a scheduling opportunity. In this way, the original scheduling order of the first access request is preserved while allowing the second access request to execute first.

[0036] After a scheduling opportunity is transferred to the second access request, its scope can be limited to the execution phase in which the second access request initially acquired the opportunity. This allows the second access request to complete that execution phase using the transferred opportunity. The scheduling status information can simultaneously record the execution phase corresponding to the scheduling opportunity, thus determining whether the scheduling opportunity remains valid after the second access request completes its execution phase. When the blocked resource is released before the end of the execution phase, the scheduling opportunity is not reused in the next execution phase after the second access request completes its current execution phase. Instead, the scheduling opportunity is returned to the first access request, allowing it to obtain the necessary flash memory access resources and perform the corresponding access operations according to its restored allocation. By limiting the scope of the scheduling opportunity in the second access request, the waiting time of the first access request can be avoided by the second access request continuously entering subsequent execution phases, and the scheduling eligibility of the first access request can be restored promptly after the blocking condition is cleared.

[0037] When multiple access requests cannot be issued due to the same blocked resource being occupied, these requests can be identified as pending access requests, and their scheduling order in the access scheduling queue can be recorded. For each pending access request, its corresponding scheduling opportunity and the association between that opportunity and the pending access request can be recorded, ensuring that scheduling opportunities transferred from different pending access requests can be returned to their respective pending access requests after the blocked resource is released. While waiting for the blocked resource to be released, the scheduling opportunities corresponding to a pending access request can be transferred to execute a second access request that meets the conditions, as described above, while retaining the original scheduling order of each pending access request. After the blocked resource is released, scheduling opportunities are returned to each pending access request in sequence according to the retained scheduling order, and other access requests following the second access request are restricted from obtaining scheduling opportunities transferred from the pending access requests, to prevent subsequent access requests from changing the original resource acquisition order among the pending access requests. Specifically, after the blocked resource is released, scheduling opportunities are returned to the pending access requests with the highest scheduling order first, allowing them to acquire the blocked resource and execute the corresponding access operation. Once the pending access request completes its access and releases the blocked resource, a scheduling opportunity is returned to the next pending access request in the scheduling queue, allowing the next pending access request to continue acquiring the blocked resource. By processing each pending access request in this manner, multiple access requests waiting for the same blocked resource can acquire the blocked resource one by one according to the scheduling order they are retained in the access scheduling queue. This improves resource utilization by utilizing the scheduling opportunity transfer mechanism while maintaining the scheduling order among pending access requests.

[0038] Example 1:

[0039] In this embodiment, the access scheduling of multiple access requests by the controller of an enterprise-grade solid-state drive (SSD) is used as an example. The enterprise-grade SSD sets up an access scheduling queue to store access requests waiting to be issued. The controller records the flash memory access resources corresponding to each access request, the execution stage, and the occupancy status of the flash memory access resources. In this embodiment, the flash memory access resources are all flash die access resources that the controller can independently schedule. A total of eight flash memory access resources, FR1 to FR8, are set up to avoid mixing resources of different levels. Access requests R1, R2, R3, R4, R5, and R6 exist sequentially in the access scheduling queue, with R1 at the head of the queue and serving as the first access request. Access requests R0 and R7 have been issued before R1 and have not yet been completed; therefore, R0 and R7 are considered prior access requests.

[0040] At the current scheduling moment, the controller reads the resource occupancy status table and determines that FR2 is occupied by R0, FR5 is occupied by R7, FR7 is occupied by another access request that has been issued but not yet completed, and FR1, FR3, FR4, FR6, and FR8 are all in an unoccupied state. The current execution phase of the first access request R1 requires both FR2 and FR3. Since FR3 is unoccupied, but FR2 is already occupied by R0, R1 cannot issue the request directly according to the current access scheduling queue order. Based on this, the controller identifies FR2, which causes R1 to be unable to issue the request, as a blocking resource. The resource occupancy status table can be updated by the controller to "occupied" when the flash memory access resource is allocated, and updated to "unoccupied" after the corresponding access request completes its use of the flash memory access resource. This allows the controller to determine whether the access request currently meets the conditions for issuance based on the resource occupancy status.

[0041] The controller further traces the resource occupancy relationship step by step along FR2, waiting for R1. For example... Figure 2 As shown, R1 first waits for FR2, which is currently occupied by the prior access request R0. R0 has not yet completed its current access operation and continues to wait for FR5. FR5 is currently occupied by the prior access request R7. R7 does not continue to wait for other flash memory access resources, thus ending this tracing path. Therefore, FR2, which R1 is directly waiting for, and FR5, which is obtained by tracing along the resource occupancy relationship, constitute the blocked resource set. Figure 2 The system also displays the occupancy status of FR1 to FR8 at the current scheduling moment. FR2 and FR5 belong to the blocked resource set, FR7 belongs to other occupied resources outside the blocked resource set, and FR1, FR3, FR4, FR6, and FR8 are all in an unoccupied state. This ensures that the waiting relationship of the first access request corresponds to the overall flash memory access resource occupancy status. When a previously recorded flash memory access resource or access request is encountered again during the tracing process, the repeated tracing of the corresponding path is stopped to avoid duplicate queries when resource waiting relationships form a cycle.

[0042] After determining the set of blocked resources, the controller assesses the number of flash access resources currently available for non-blocking access requests. To quantify the availability of current flash access resources, a ratio of available flash access resources is set. :

[0043]

[0044] in, This indicates the proportion of flash access resources that are currently unaffected by blocking and can be used by subsequent access requests. The subscript 'a' indicates the status of available resources. This indicates the number of flash memory access resources that are currently unoccupied and do not belong to the blocked resource set; This indicates the total number of flash memory access resources considered in this scheduling judgment. The controller iterates through the resource occupancy status table, excluding flash access resources that are in an occupied state and flash access resources that belong to the blocked resource set, to obtain the result. The range of flash memory access resources involved in this access scheduling judgment is determined. This embodiment examines eight flash memory access resources, FR1 to FR8. FR2 and FR5 belong to the blocked resource set and are both occupied. FR7 is also occupied. FR1, FR3, FR4, FR6, and FR8 meet the conditions of being unoccupied and not belonging to the blocked resource set. Therefore... The value is 5. The value is 8. The corresponding calculation process is as follows:

[0045]

[0046] like Figure 3 As shown above, FR1, FR3, FR4, FR6, and FR8 constitute the five currently available flash memory access resources; FR2, FR5, and FR7 are not included. ,therefore The percentage was 62.5%. This result indicates that although the first access request R1 could not be issued because FR2 was occupied, there were still multiple flash access resources available for executing other access requests. Based on this, the controller continued to perform candidate filtering from the access requests after R1, instead of having all subsequent access requests in the access scheduling queue wait for FR2 to be released. In this embodiment, the resource base used to reflect the current non-blocking scheduling is calculated without changing the original data access order requirements between access requests.

[0047] The controller analyzes the resource requirements and data access order dependencies for R2 to R6 sequentially, with specific filtering relationships as follows: Figure 3As shown in the lower section. R2 currently requires FR1. FR1 is not occupied and does not belong to the blocked resource set. However, R2 and the already issued R0 access at least partially share the same logical address range, and there is a write order relationship that needs to be maintained between them. Therefore, R2 has a data access order dependency with the earlier access request R0, and R2 is not identified as a candidate access request. R4 currently requires FR5. Since FR5 is already occupied and belongs to the blocked resource set, R4 does not meet the conditions that the required resource is not occupied and that it has no intersection with the blocked resource set. R6 currently requires FR7, but FR7 is still occupied by other issued but not yet completed access requests. Therefore, R6 does not meet the condition that the required flash memory access resource is not occupied. R3 currently requires FR4 and FR6. Both flash memory access resources are not occupied and do not belong to the blocked resource set. Furthermore, R3 has no data access order dependency with R0 and R7. Therefore, R3 is identified as a candidate access request. R5 currently requires FR3. FR3 is not occupied and does not belong to the blocked resource set. Furthermore, R5 does not have a data access order dependency with prior access requests. Therefore, R5 is also identified as a candidate access request. By mapping different filtering conditions to each subsequent access request, resource conflicts or changes in access order can be avoided by determining the second access request solely based on the idle status of a single resource.

[0048] For candidate access request R5, FR3 is also a flash memory access resource required for the execution of the first access request R1. Therefore, FR3 is a flash memory access resource shared by R5 and R1. Based on the request status of the current execution phase of R5 and the resource release order, the controller determines that R5 will complete its current execution phase and release FR3 approximately 18 μs after acquiring it. Based on the current execution status of R0, which occupies FR2, and R0's waiting status for FR5, the controller determines that FR2 is expected to be released from its occupancy in approximately 34 μs. Since 18 μs is less than 34 μs, it can be determined that R5 can release FR3, shared with the first access request R1, before the blocked resource FR2 is released from its occupancy. R5 meets the further screening criteria for candidate access requests. After R5 releases FR3, its adjacent next execution phase needs to acquire FR1. FR1 is currently unoccupied; therefore, after R5 releases FR3, which was occupied by the previous execution phase, it can acquire FR1 without waiting for other access requests to release resources. The above time data is used to characterize the sequential relationship of different resource release events in this embodiment and is not intended to limit the fixed performance parameters of enterprise-level solid-state drives.

[0049] The controller simultaneously compares the resource switching relationships between adjacent execution phases of candidate access request R3. After R3 is issued, its current execution phase can acquire unoccupied FR4 and FR6. After the current execution phase ends, it releases FR4 and FR6 and acquires FR8 in the next adjacent execution phase. Since FR8 is currently unoccupied, R3 can acquire FR8 without waiting for other access requests to release resources after releasing the flash access resources occupied by the previous execution phase. Figure 4 As shown on the right, the resource switching relationship corresponding to R3 is switching from FR4 and FR6 to FR8, and the resource switching relationship corresponding to R5 is switching from FR3 to FR1. Both can complete the resource switching between adjacent execution stages without relying on other access requests to release resources. Therefore, the controller further filters based on the different flash memory access resources that can be released after the two complete their respective execution processes.

[0050] To ensure a clear selection criterion among multiple candidate access requests that meet scheduling conditions, a resource release evaluation value for each candidate access request is set. :

[0051]

[0052] in, This represents the resource release evaluation value for the corresponding candidate access request, with the subscript c indicating the candidate access request; This indicates the number of different flash memory access resources that can be released after the candidate access request completes this continuous execution process; This indicates the number of different flash memory resources that need to be acquired when the candidate access request moves from the current execution phase to the next execution phase. The controller determines this based on the resource mapping relationships and resource release status corresponding to each execution stage of the access request. Determined based on changes in flash memory access resource requirements between the current execution phase and the next execution phase. This is used to characterize the relationship between the number of different flash memory access resources that can be released when a candidate access request acquires a certain amount of additional flash memory access resources. When multiple candidate access requests all meet the conditions of having no intersection with the blocked resource set, no data access order dependency, and the required flash memory access resources being in an unoccupied state, this can be combined with... Further screening will be conducted.

[0053] In this embodiment, R3 acquires FR4 and FR6 in the current execution phase, and acquires FR8 in the next execution phase. After completing the corresponding execution process, it can release three different flash memory access resources: FR4, FR6, and FR8. Therefore, R3 corresponds to... The value is 3. When the value is 1, its resource release evaluation value is:

[0054]

[0055] In the current execution phase, R5 acquires FR3, and in the next execution phase, it acquires FR1. After completing the above continuous execution process, it can release the two different flash memory access resources, FR3 and FR1. Therefore, R5 corresponds to... The value is 2. When the value is 1, its resource release evaluation value is:

[0056]

[0057] like Figure 4 As shown in the bar chart, both R3 and R5 can release two or more different flash memory access resources after execution, meeting the priority filtering criteria. Among them, R3 corresponds to... For 3, R5 corresponds to The value is 2. Since R3 can release three different flash access resources when acquiring one new flash access resource, while R5 releases two different flash access resources, the controller prioritizes R3 as the second access request and issues R3 before the first access request R1. R3 first uses FR4 and FR6 to execute the current stage, and after releasing FR4 and FR6, it acquires FR8 to execute the next stage. This ensures that while R1 is waiting for FR2 to be released, FR4, FR6, and FR8 can still participate in the access request execution.

[0058] After R3 completes its access, it releases FR4, FR6, and FR8, and the controller updates the corresponding resource occupancy status to unoccupied. If FR2 is still occupied at this time, the controller re-examines the candidate access requests in the access scheduling queue. R5, which still meets the requirements, can then be issued as the second access request. R5 acquires FR3 to execute the current phase and releases FR3 after approximately 18 μs, subsequently acquiring FR1 to enter the next execution phase. If R5 needs to acquire FR3 again in a subsequent execution phase after completing the access operation corresponding to FR1, and the controller detects that FR2 has been released before R5 completes the execution phase corresponding to FR1, R5 is not allowed to acquire FR3. Instead, after R5 completes the current FR1 execution phase, its acquisition of FR3 is paused, allowing the first access request R1 to acquire FR2 and FR3 first. After R1 finishes using FR3 and releases it, R5 is allowed to acquire FR3 and continue execution. This control process allows the second access request to utilize currently available resources while preventing it from occupying the shared flash memory access resources required for the first access request to resume execution in subsequent phases.

[0059] After R7 completes its access and releases FR5, the controller updates FR5 to an unoccupied state and allows R0, which was waiting for FR5, to acquire it and continue execution. After R0 completes its access phase, it releases FR2, thus detecting that the blocked resource FR2, which the first access request R1 was directly waiting for, is no longer occupied. The controller reassesses the occupancy status of FR2 and FR3 required by R1. If both FR2 and FR3 are available, it issues a request to R1, enabling R1 to execute the corresponding access operation. For FR4, FR6, and FR8, which R3 has already released, and other subsequently released flash memory access resources, the controller continues to allocate resources based on the resource requirements of each access request in the access scheduling queue, the set of blocked resources, and data access order dependencies. Figure 2 The blocking relationship shown is traced back. Figure 3 The resource status and candidate access request filtering shown are as follows: Figure 4 The resource release evaluation and adjacent execution phase switching shown can, while maintaining the data access order requirements between access requests and the conditions for the first access request to resume execution, allow flash access resources that are not affected by the blocked resource set to continue to be used to execute other access requests that meet the conditions during the waiting period of the first access request in the queue. This reduces the idle flash access resources caused by the blocking of the first access request in the queue and achieves access load balancing for enterprise-level solid-state drives.

[0060] Example 2:

[0061] In this embodiment, the scheduling of access requests in the access scheduling queue by the controller of an enterprise-level solid-state drive is used as an example. The access scheduling queue contains access requests R1, R2, R3, R4, R5, and R6 in sequence, with R1 at the head of the queue and serving as the first access request. R2 and R3 follow R1. Another access request, R0, has been issued but not yet completed, occupying flash memory access resource FR2. The current execution phases of R1, R2, and R3 all require FR2, while the current execution phase of R4 requires the unoccupied FR4. Furthermore, there is no data access order dependency between R4 and R0, and the flash memory access resource currently required by R4 does not overlap with FR2. Therefore, when R1 cannot be issued due to FR2 being occupied, R4 can be designated as the second access request.

[0062] The controller determines whether to allocate resources to R1 according to the scheduling order in the access scheduling queue. Since R1 already has the qualification to allocate resources according to the current scheduling order, but FR2, which its current execution phase requires, is still occupied by R0, the controller does not cancel R1's already acquired allocation qualification. Instead, it designates this allocation qualification as a scheduling opportunity for R1. A scheduling opportunity represents an allocation qualification that an access request has acquired according to the current scheduling order of the access scheduling queue but cannot be actually used temporarily; it is not a newly added physical resource. The controller can record the source access request, original scheduling order, currently associated access request, and allowed execution phase in the scheduling status information for the scheduling opportunity. For example... Figure 5 As shown, the first access request R1 remains in the original scheduling position 1. It cannot be executed temporarily because it is waiting for FR2, but the issuance qualification corresponding to R1 is still retained, thus separating the resource blocking state from the scheduling qualification state.

[0063] While R1 continues to wait for FR2 to release its occupancy, the controller temporarily associates the scheduling opportunity corresponding to R1 with the second access request R4, so that R4 can use the scheduling opportunity to issue the request before R1 and obtain FR4, which is currently in an unoccupied state, to execute its current execution phase. Figure 5 The temporary transfer relationship between the scheduling opportunity corresponding to R1 and the current execution stage of R4 indicates that the transfer involves the allocation qualification already acquired by R1, not R1's original scheduling position. After R4 acquires the scheduling opportunity, it executes first using FR4, and the scheduling status information still retains the information that the scheduling opportunity originated from R1 and R1's original scheduling order. Therefore, the first execution of R4 does not change the scheduling position already reserved for R1 in the access scheduling queue. For access requests that have not yet acquired a corresponding scheduling opportunity after R1, they are not allowed to obtain a recovery allocation order superior to R1 due to the first execution of R4.

[0064] After a scheduling opportunity is transferred to R4, the controller restricts the scope of that opportunity to the current execution phase in which R4 acquired the opportunity. To determine whether the release time of FR2 is earlier than the end time of R4's current execution phase, the remaining duration of the current execution phase of the second access request is set. The time elapsed from the current judgment moment to the release of the blocked resource. and stage switching judgment quantity .in, and All are represented by μs. It is used to characterize the temporal sequence between the end of the current execution phase and the release of blocked resources, and its calculation formula is:

[0065]

[0066] in, This indicates the remaining time required for R4 to complete the current execution phase from the current judgment time. This parameter is determined by the controller based on the current execution state of R4 and the remaining operations of the corresponding execution phase. This parameter represents the time elapsed from the current judgment moment until FR2 is released from its occupancy. This parameter is determined based on the current execution status of R0, which occupies FR2, and the remaining resource usage process. This indicates the time difference between the two. When When it is greater than 0, it means Less than That is, FR2 releases its hold before the current execution phase of R4 ends; when When equal to 0, it indicates that the release of FR2 from occupancy and the end of the current execution phase of R4 occur simultaneously under the current timing precision; when When the value is less than 0, it means that the current execution phase of R4 ends before FR2 is released from its occupancy.

[0067] In this embodiment, the controller determines based on the current execution state of R4. The value is 40 μs, determined based on the remaining occupancy status of R0 for FR2. The value is 25 μs. Substituting the corresponding data, we get...

[0068]

[0069] like Figure 6 As shown, the current execution phase of R4 requires another 40 μs from the current judgment time, while FR2 is released after being occupied by R0 for another 25 μs. Therefore, a 15 μs time interval is formed between 25 μs and 40 μs. This time interval is formed by... Characterization. Due to If the time is 15 μs and greater than 0, FR2 will be released from its current execution phase before R4. After detecting that FR2 has been released from its current execution phase, the controller will not interrupt the current execution phase that R4 has started, but will allow R4 to complete the execution phase. After R4 completes the current execution phase, it will no longer allow the scheduling opportunity transferred from R1 to be used for the next execution phase, and will re-associate the scheduling opportunity to R1. Figure 5 The relationship between the release of FR2 from occupancy and the return of the scheduling opportunity to R1 further corresponds to the above processing procedure. That is, the release of FR2 from occupancy constitutes the recovery condition for returning the scheduling opportunity, while the end of the current execution phase of R4 constitutes the phase boundary for the actual execution of the return operation.

[0070] After the scheduling opportunity returns to R1, R1 regains the right to issue requests based on the original scheduling order and makes a decision on whether to issue a request before any subsequent access requests have been scheduled. The controller issues a request to R1 when FR2 and other flash memory access resources required for the current execution phase of R1 are available. If FR2 has been released from its occupancy but the current execution phase of R4 has not yet ended, R1 remains in a state of waiting for the scheduling opportunity to return, without forcibly interrupting R4, thus ensuring that the return time of the scheduling opportunity corresponds to the execution phase boundary of the second access request.

[0071] For R2 and R3, when the controller checks the waiting status in the access scheduling queue, it determines that the current execution phase of R2 and R3 also requires FR2, and FR2 is still occupied by R0. Therefore, R1, R2, and R3 are identified as pending access requests waiting for the same blocked resource. The controller saves the original scheduling order of R1, R2, and R3 in the access scheduling queue, where R1 corresponds to the first scheduling position, R2 to the second scheduling position, and R3 to the third scheduling position. Each pending access request retains its scheduling status information corresponding to its original scheduling order during the waiting period. Access requests following these pending access requests cannot obtain the scheduling opportunities transferred from these pending access requests and thus change the original resource acquisition order among R1, R2, and R3.

[0072] To quantify and record the waiting status of each pending access request and the status of scheduling opportunity return, a priority value for scheduling opportunity return is set without changing the original scheduling order. Its calculation formula is

[0073]

[0074] in, This indicates the priority value for the return of the scheduling opportunity corresponding to the access request to be restored. The subscript q indicates that this parameter is related to the return status of the scheduling opportunity. This indicates the time that the corresponding access request to be restored has been waiting for the blocked resource, in μs. This parameter is determined by the controller based on the time interval between the moment when the access request entered the blocked waiting state and the current scheduling moment. This indicates the scheduling order parameter that the access request to be restored is retained in the original access scheduling queue. A value of 1 indicates the first position in the original scheduling. A value of 2 indicates the second position in the original scheduling sequence, and so on. Because... Since it is a dimensionless scheduling order parameter, therefore and They have the same time dimension. Under the same circumstances, The larger, The larger; in Under the same circumstances, The smaller, The larger. Used to record the waiting level of access requests awaiting recovery and to assist in verifying the return status of scheduling opportunities. The actual return order of scheduling opportunities is still based on... The original scheduling order shall prevail, and no use shall be made. This causes a later-ordered access request to override a earlier-ordered access request.

[0075] In one set of example states, R1 has been waiting for FR2 for 90 μs. The value is 1; R2 has been waiting for FR2 for 72 μs. The value is 2; R3 has been waiting for FR2 for 60 μs. The value is 3. The priority value for the scheduler corresponding to R1 to return is...

[0076]

[0077] The priority value for the scheduling opportunity corresponding to R2 is...

[0078]

[0079] The priority value for the scheduling opportunity corresponding to R3 is...

[0080]

[0081] like Figure 7 As shown, R1, R2, and R3 correspond to The time intervals are 90 μs, 36 μs, and 20 μs, respectively, and the original scheduling information for the first scheduling position of R1, the second scheduling position of R2, and the third scheduling position of R3 is also retained in the figure. The controller... The actual scheduling opportunity return order is determined to be R1, R2, R3, and... This is used to reflect the waiting status of each pending access request at its corresponding scheduling position, and is not used as the sole basis for crossing the original scheduling order. When R0 releases FR2, it first returns the corresponding scheduling opportunity to R1, enabling R1 to acquire FR2 and execute the corresponding access operation; after R1 acquires FR2, R2 and R3 remain in the pending state, and other access requests located after R2 and R3 cannot bypass the corresponding pending access request by acquiring a scheduling opportunity transferred by R2 or R3 that is still pending.

[0082] After R1 completes its access to FR2 and releases FR2, the controller returns the corresponding scheduling opportunity to R2 according to the saved scheduling order, allowing R2 to acquire FR2 and execute its current access operation. While R2 is holding FR2, R3 remains in a waiting state. After R2 completes its access and releases FR2, it returns the corresponding scheduling opportunity to R3, allowing R3 to acquire FR2. If, during the previous waiting period, R2 or R3 has other access requests that meet the prior execution conditions and temporarily use its scheduling opportunity, the temporary association of the corresponding scheduling opportunity ends when FR2 can be acquired by the corresponding pending access request, and the corresponding scheduling opportunity is prohibited from being passed to the next execution stage of the temporary access request.

[0083] Through the above methods, it is possible to utilize Figure 5 The scheduling opportunity shown involves temporary transfer and return relationships, allowing a second access request that meets the conditions to be executed first using other unoccupied flash memory access resources while the first access request is blocked; combined with Figure 6 The execution phase and the timing relationship of blocking resource removal shown indicate that after the blocking condition is removed, a scheduling opportunity is returned according to the execution phase boundary of the second access request; and combined with... Figure 7 The waiting status and original scheduling order of the access requests to be restored shown are restored in sequence when multiple access requests are waiting for the same blocked resource. This allows the access requests to continue to be executed using unblocked flash memory access resources while maintaining the original scheduling order among the access requests to be restored.

Claims

1. A method for load balancing access to enterprise-level solid-state drives, characterized in that, include: Retrieve multiple access requests from the access scheduling queue and determine the flash memory access resources corresponding to each access request and their occupancy status. When the first access request at the head of the access scheduling queue cannot be sent because the required flash memory access resources are occupied by a prior access request that has been sent but not yet completed, the blocking resource is determined according to the resource occupation relationship between the first access request and the prior access request. From the access requests after the first access request, a second access request is selected where the required flash memory access resources do not intersect with the blocking resource, there is no data access order dependency with the prior access request, and the required flash memory access resources are not occupied. The second access request is sent before the first access request, and the first access request is sent after the blocked resource is unoccupied, so as to use the unoccupied flash memory access resources that do not intersect with the blocked resource to execute the access request, thereby achieving access load balancing.

2. The access load balancing method for an enterprise-level solid-state drive according to claim 1, characterized in that, Following the flash memory access resources waiting for the first access request, the access requests occupying the corresponding flash memory access resources and the flash memory access resources that the access requests continue to wait for are traced level by level. The traced flash memory access resources are formed into a blocked resource set, and the access requests that do not intersect with the blocked resource set are selected from the access requests after the first access request as the second access request.

3. The access load balancing method for an enterprise-level solid-state drive according to claim 1, characterized in that, Based on the occupancy status of flash memory access resources in adjacent execution phases of candidate access requests, a candidate access request that can use unoccupied flash memory access resources and releases the flash memory access resources shared with the first access request before the blocking resources are unoccupied is selected as the second access request.

4. The access load balancing method for an enterprise-level solid-state drive according to claim 1, characterized in that, When the first access request cannot be sent due to the blocking resource being occupied, the sending qualification obtained by the first access request according to the scheduling order of the access scheduling queue is determined as a scheduling opportunity, and the scheduling opportunity is transferred to the second access request. After the blocked resource is released from its occupancy, the scheduling opportunity is returned to the first access request, so that the first access request is issued before any subsequent access request has obtained a scheduling opportunity.

5. The access load balancing method for an enterprise-level solid-state drive according to claim 3, characterized in that, When determining the candidate access request, the resource switching relationship between one execution stage of the candidate access request and the adjacent next execution stage is compared. The candidate access request that can obtain another unoccupied flash memory access resource without waiting for the resource to be released after the flash memory access resource occupied by the previous execution stage is released is given priority as the second access request, so as to reduce resource waiting between adjacent execution stages.

6. The access load balancing method for an enterprise-level solid-state drive according to claim 3, characterized in that, During the execution of the second access request, it is monitored whether the next execution phase of the second access request needs to reclaim the flash memory access resources shared with the first access request. If so, the second access request is suspended from acquiring the shared flash memory access resources before entering the next execution phase. After the blocked resources are unoccupied, the first access request acquires the corresponding flash memory access resources first, and then the second access request is allowed to acquire the corresponding flash memory access resources.

7. The access load balancing method for an enterprise-level solid-state drive according to claim 3, characterized in that, When multiple candidate access requests can use unoccupied flash memory access resources, the candidate access request that can release two or more different flash memory access resources after execution is preferentially determined as the second access request, and the released flash memory access resources are allocated to subsequent access requests that are in a waiting state and whose required flash memory access resources do not intersect with the blocked resources.

8. The access load balancing method for an enterprise-level solid-state drive according to claim 4, characterized in that, After the scheduling opportunity is transferred to the second access request, the second access request completes the execution phase in which it obtained the scheduling opportunity. When the blocked resource is released from occupation before the end of the execution phase, the scheduling opportunity is no longer passed to the next execution phase of the second access request, and the scheduling opportunity is returned to the first access request.

9. The access load balancing method for an enterprise-level solid-state drive according to claim 4, characterized in that, When multiple access requests cannot be sent due to the blocking resource being occupied, the multiple access requests are identified as access requests to be restored, and the scheduling order of each access request to be restored in the access scheduling queue is retained. After the blocking resource is released, scheduling opportunities are returned to the access requests to be restored in sequence according to the retained scheduling order, and access requests following the second access request are prohibited from obtaining the scheduling opportunities transferred by the access requests to be restored.

10. The access load balancing method for an enterprise-level solid-state drive according to claim 9, characterized in that, After the blocked resource is released from its occupancy, a scheduling opportunity is returned to each pending access request in the scheduling order. After each pending access request acquires the blocked resource, completes the access, and releases the blocked resource, a scheduling opportunity is returned to the next pending access request in the scheduling order, so that the pending access requests acquire the blocked resource one by one in the scheduling order.

Images