A data reading method, a data access accelerator and an electronic device

Abstract

The application discloses a data reading method, a data access accelerator and an electronic device. A target access request of a target application is obtained. In response to the target access request satisfying a prefetch matching condition, a target access feature set matched with the target application is obtained from a historical access feature set. The historical access feature set includes a plurality of historical access feature sets respectively corresponding to a plurality of applications. Each historical access feature set includes access parameters of a historical access request sequence of a corresponding application. The historical access request sequence includes a plurality of historical access requests. Based on the target access feature set, a target access request sequence is generated. The target access request sequence includes the target access request and a plurality of predicted access requests after the target access request. Data reading is performed based on the target access request sequence.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data reading method, a data access accelerator, and an electronic device. Background Technology

[0002] In computer systems, the central processing unit (CPU) has high data processing efficiency, while storage devices have lower data transfer efficiency. Currently, the common approach is to respond as a request arrives. This means that access requests initiated by application services must be passed through multiple layers of the software stack before reaching the CPU. The CPU only reads data from the storage device after receiving the request. This forces the CPU to wait for a response from the storage device, thus affecting the overall data retrieval efficiency of the computer system. Summary of the Invention

[0003] This application provides a data reading method, a data access accelerator, and an electronic device, the specific solutions of which are as follows:

[0004] A data reading method, comprising:

[0005] Obtain the target application's target access request;

[0006] In response to the target access request satisfying the prefetch matching condition, a target access feature set matching the target application is obtained from the historical access feature set. The historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application. The historical access request sequence includes multiple historical access requests.

[0007] Based on the target access feature set, a target access request sequence is generated, the target access request sequence including the target access request and multiple predicted access requests following the target access request;

[0008] Data is read based on the target access request sequence.

[0009] Furthermore, the method for determining whether the target access request satisfies the prefetch matching conditions includes:

[0010] Obtain the target application identifier from the target access request, wherein the target application identifier corresponds to the target application;

[0011] The target application identifier is compared with several historical application identifiers, wherein each historical application identifier corresponds to a different historical access feature set within the historical access feature set.

[0012] In response to the target application identifier matching a first historical application identifier among the plurality of historical application identifiers, it is determined that the target access request satisfies a first prefetch matching condition.

[0013] Furthermore, the method for determining whether the target access request satisfies the prefetch matching condition also includes:

[0014] In response to the matching of the target application identifier with the first historical application identifier, a target access feature set corresponding to the first historical application identifier is determined;

[0015] The target application identifier of the target access request is compared with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set;

[0016] In response to the target application identifier of the target access request matching the request identifier corresponding to the first request in the historical access request sequence of the target access feature set, it is determined that the target access request satisfies the second prefetch matching condition.

[0017] Furthermore, the method for determining whether the target access request satisfies the prefetch matching condition also includes:

[0018] In response to the target application identifier of the target access request being matched with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set, the key access parameters of the target access request are determined.

[0019] The key access parameters are compared with the key access parameters in the access parameters of the first request;

[0020] In response to the key access parameter matching the key access parameter in the access parameter of the first request, it is determined that the target access request satisfies the third prefetch matching condition.

[0021] Furthermore, it also includes:

[0022] In response to the target access request not satisfying any one of the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition, data is read based on the content of the target access request.

[0023] Furthermore, it also includes:

[0024] In response to the target access request not satisfying the first prefetch matching condition, a historical access feature set corresponding to the target application identifier is added to the historical access feature set, and access parameters in the historical access feature set corresponding to the target application identifier are determined based on the target access request.

[0025] Furthermore, it also includes:

[0026] In response to the target access request not satisfying the second prefetch matching condition or the third prefetch matching condition, the access parameters in the historical access feature set corresponding to the target application identifier in the historical access feature set are updated based on the target access request.

[0027] A data access accelerator, comprising:

[0028] A parser is used to obtain the target access request of the target application and parse the target access request to obtain the parsing result;

[0029] The processor is configured to, in response to the parsing result indicating that the target access request satisfies the prefetch matching condition, obtain a target access feature set matching the target application from the historical access feature set, wherein the historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively, each historical access feature set includes access parameters of the historical access request sequence of the corresponding application, and the historical access request sequence includes multiple historical access requests.

[0030] A sequence generator is used to generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and a plurality of predicted access requests following the target access request, so as to perform data reading based on the target access request sequence.

[0031] Furthermore, it also includes:

[0032] A first memory is used to store the set of historical access features.

[0033] An electronic device, comprising:

[0034] The request side is used to output the target application's target access request;

[0035] The second memory is used to store historical access feature sets, which include multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application, and the historical access request sequence includes multiple historical access requests.

[0036] A data access accelerator is used to obtain the target access request output by the requesting end, and in response to the target access request satisfying the prefetch matching condition, to obtain a target access feature set matching the target application from the historical access feature set, and to generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and a plurality of predicted access requests following the target access request; and to perform data reading based on the target access request sequence. Attached Figure Description

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

[0038] Figure 1 This is a flowchart of a data reading method disclosed in an embodiment of this application;

[0039] Figure 2a This is a schematic diagram of a storage subsystem including a data access accelerator disclosed in an embodiment of this application;

[0040] Figure 2b This is a schematic diagram of multiple functional fields in a configuration register disclosed in an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of a set of historical access features disclosed in an embodiment of this application;

[0042] Figure 4 This is a flowchart of a data reading method disclosed in an embodiment of this application;

[0043] Figure 5 This is a schematic diagram of the processing flow of a data access accelerator corresponding to a data reading method disclosed in an embodiment of this application;

[0044] Figure 6 This is a flowchart of a data reading method disclosed in an embodiment of this application;

[0045] Figure 7 This is a flowchart of a data reading method disclosed in an embodiment of this application;

[0046] Figure 8 This is a schematic diagram showing the access parameters corresponding to each request in a historical access feature set disclosed in an embodiment of this application;

[0047] Figure 9 This is a flowchart of a data reading method disclosed in an embodiment of this application;

[0048] Figure 10 This is a schematic diagram of the structure of a data access accelerator disclosed in an embodiment of this application;

[0049] Figure 11 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. Detailed Implementation

[0050] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0051] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0052] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0053] This application discloses a data reading method, the flowchart of which is as follows: Figure 1 As shown, it includes:

[0054] Step S101: Obtain the target access request of the target application;

[0055] Step S102: In response to the target access request satisfying the prefetch matching condition, obtain the target access feature set matching the target application from the historical access feature set. The historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application. The historical access request sequence includes multiple historical access requests.

[0056] Step S103: Based on the target access feature set, generate a target access request sequence, which includes the target access request and multiple predicted access requests following the target access request.

[0057] Step S104: Read data based on the target access request sequence.

[0058] In computer systems, the central processing unit (CPU) has high data processing efficiency, while the data transfer efficiency of storage devices is relatively low. The difference in data transfer rates between the CPU and storage devices affects the overall system performance. This problem is particularly pronounced when the storage device is an external, low-speed storage device connected via an I / O interface.

[0059] Currently, large access requests initiated by upper-layer applications need to be broken down at the Block layer. Each smaller request then needs to be passed through multiple software stacks, and finally converted into protocol hardware signals by the main controller before interacting with the storage device. This approach means that each small request needs to trigger a complete software stack processing flow. During this process, the CPU needs to wait for a response from the storage device, resulting in a significant amount of waiting time and exacerbating the difference in data transfer rates between the CPU and the storage device.

[0060] Based on this, in this solution, in response to the target application's target access request satisfying the prefetch matching condition, a target access feature set matching the target application is obtained from the historical access feature set. This is used to generate a target access request and multiple subsequent predicted access requests based on the target access feature set, thereby enabling data reading. Since multiple predicted access requests can be generated directly when the target access request satisfies the prefetch matching condition, and the data required for subsequent requests can be prefetched based on these predicted access requests, the data can be directly retrieved when subsequent requests arrive, eliminating the need to access the storage device for data reading. This improves the data transfer efficiency between the memory and the processor, thereby enhancing system performance.

[0061] The data reading method disclosed in this embodiment is applied to a data access accelerator, which can perform hardware prefetching acceleration for application or process service-level input / output requests, such as access requests based on IO interfaces, thereby reducing the complexity of the system input / output interaction process and improving data reading efficiency.

[0062] like Figure 2a The diagram illustrates a storage subsystem including a data access accelerator. This subsystem connects to both the system-on-a-chip (SOC) and the storage devices within the computer system. The storage subsystem includes a main controller, a data access accelerator, and a bridging module. The main controller is bridged to the SOC's internal bus via the bridging module, and the data access accelerator is also connected to the SOC bus via the same bridging module. Register initialization configuration information is sent to both the main controller and the data access accelerator via the bridging module to complete initialization settings. The main controller also converts data read requests issued by the application through the software layer or the data access accelerator into protocol hardware signals and performs data transmission and reception with the storage devices. The data access accelerator receives the register initialization configuration information through the bridging module, completes acceleration enable settings based on this information, and performs accelerated processing of the data read request based on historical access feature sets when the access request or access request sequence meets the prefetch matching conditions.

[0063] The data access accelerator may include a configuration register containing multiple functional fields to carry control parameters issued by the software layer. The hardware uses these control parameters to parse and accelerate access requests. Alternatively, the data access accelerator may include multiple configuration registers, each corresponding to a different functional field.

[0064] like Figure 2b The diagram shows a configuration register with multiple functional fields disclosed in this embodiment. These functional fields may include: an enable control field, a status indicator field, an acceleration flag field, an application identifier field, and a request sequence number field. The enable control field has a bit field of [1,0] and is read-write. It controls the start or stop of the data access accelerator. Writing a first value to the enable control field disables the data access accelerator, and writing a second value enables it. The first value can be 00, the second value can be 01, or other values, which are not specifically limited here. The status indicator field has a bit field of [3,2] and is read-only. It indicates the current working status of the data access accelerator. Reading the status indicator field allows us to determine whether the data access accelerator is performing an acceleration operation for system scheduling or anomaly diagnosis. The acceleration flag field has a bit field of [4] and is read-only. The acceleration flag field is used when constructing a request. The write field indicates whether the current request needs to be accelerated. When the acceleration flag field is written with the third value, it means that the current request should enter the acceleration process. When the acceleration flag field is written with the fourth value, it means that the current request does not need to be accelerated. The third value can be 1 and the fourth value can be 0. Of course, other values ​​are also possible, and no specific limitation is made here. The application identifier field has a bit field of [14,5] and is read-write. The application identifier field is used to carry the application identifier corresponding to the current request. Different application services are distinguished by the application identifier. The valid range of the application identifier can be 0-1023. Application identifiers outside this valid range are invalid values. The request sequence number field has a bit field of [24,15] and is read-write. The request sequence number field is used to carry the sequential position of the current request in its respective request sequence.

[0065] During computer system operation, upper-layer application services may initiate large access requests. These large access requests are broken down into multiple smaller requests at the Block layer. The data access accelerator can receive these smaller requests, which are the access requests involved in this embodiment. Specifically, the data access accelerator continuously monitors access requests on the system bus. When an upper-layer application initiates a data read operation, its smaller requests are transmitted via the computer system bus. The data access accelerator obtains this current smaller request, i.e., the target access request, from the system bus. The upper-layer application that outputs this smaller request is the target application.

[0066] The historical access feature set is pre-stored in the static random access memory inside the data access accelerator. This historical access feature set records the historical access feature sets of different applications during their historical operation. The historical access feature set is divided by application, with each application corresponding to one historical access feature set. Each historical access feature set contains one or more historical access request sequences, and each historical access request sequence is composed of multiple historical access requests in sequence. Each historical access request has its own access parameters.

[0067] like Figure 3 The diagram illustrates a set of historical access features, comprising: a historical access feature set for application 1 and a historical access feature set for application 2. Each application's historical access feature set includes access parameters corresponding to multiple request sequences. Taking application 1 as an example, the historical access feature set for application 1 includes access parameters corresponding to request sequence 11 and request sequence 12. Request sequence 11 includes three requests: request 111, request 112, and request 113. The access parameter for request 111 is access parameter 111, the access parameter for request 112 is access parameter 112, and the access parameter for request 113 is access parameter 113. Figure 3 The applications, request sequences, and requests included are all identifiers, not the detailed content of the specific requests or request sequences.

[0068] The access parameters may include: an access address representing the data to be read, the starting position of the data within the storage range corresponding to the access address, and the length of the data at the corresponding address in the storage device that can be accessed based on the access parameters. Specifically, the access address representing the data to be read can be a page address, which can be a page sector corresponding to the access request; the starting position of the data within the storage range corresponding to the access address can be an offset within the page, which can be an offset within the sector; and the length of the data at the corresponding address in the storage device that can be accessed based on the access parameters can be the data length, which can be the length of the access request. These parameters uniquely characterize the features of an access request, allowing a complete access request to be reconstructed based on these parameters, and a complete target access request sequence to be obtained from multiple constructed access requests.

[0069] After obtaining the current target access request, the data access accelerator determines whether the request meets the prefetch matching condition. The prefetch matching condition means that the data access accelerator can identify that the target application is currently in a predictable access state based on the historical access feature set, thereby generating multiple subsequent predicted access requests for the target access request.

[0070] After the data access accelerator determines that the target access request meets the prefetch matching conditions, it retrieves the target access feature set corresponding to the target application from the historical access feature set. This target access feature set is the access parameter corresponding to each access request in the target access request sequence corresponding to the target application in the historical access feature set.

[0071] Based on the set of historical access features Figure 3 Taking this example, if a target access request that meets the prefetch matching conditions corresponds to request sequence 12 in the feature set of application 1, then the target access feature set includes: access parameters corresponding to each request in request sequence 12. Here, request sequence 12 is a historical request sequence in the historical access feature set that includes the target access request. This historical request sequence includes not only the target access request but also the access requests following the target access request. The access requests following the target access request in this historical request sequence are determined as the predicted access requests following the target access request in this embodiment.

[0072] After obtaining the target access feature set, the corresponding access requests are obtained based on the access parameters corresponding to each request in the target access feature set. These access requests are then combined sequentially to obtain the target access request sequence. In this process, multiple predicted access requests following the target access request can be generated directly without waiting for the target application to output subsequent access requests after the target access request. This reduces the waiting time for the target application to issue subsequent access requests, allowing the target access request and multiple predicted access requests following the target access request to be generated in the target access request sequence at once.

[0073] After generating the target access request sequence, the data corresponding to each access request in the target access request sequence can be read directly based on the complete target access request sequence, so as to achieve the reading of the data corresponding to each access request in the target access request sequence at one time.

[0074] Specifically, after generating the target access request sequence, each access request in the sequence can be sent sequentially to the main controller. Upon receiving the target access request sequence, the main controller interacts with the storage device in the order of the access requests, reading the data corresponding to each access request from the storage device. The read data can be directly transferred to a memory buffer pre-allocated by the driver via memory access, thus achieving pre-reading of the data. When the target application subsequently issues a subsequent access request, since the data access accelerator has already pre-read and stored the corresponding data in memory, the target application can directly retrieve the data from memory without triggering the complete software stack processing flow again, thereby significantly reducing data access latency.

[0075] The data reading method disclosed in this embodiment pre-stores a historical access feature set, which includes historical access feature sets corresponding to multiple applications. When a target access request of a target application is obtained, a matching target access feature set is determined from the historical access feature set based on the target application identifier of the target access request. The target access feature set records the access parameters of each historical access request in a specific historical access request sequence during the historical operation of the target application. Based on the target access feature set in the historical access feature set, the access requests after the current target access request are predicted, so that data can be read in advance based on the predicted access requests, thereby improving the efficiency of data reading and improving the performance of the computer system. Furthermore, since the predicted access requests are generated based on accesses that have actually occurred in the historical access feature set, the accuracy of the prediction is guaranteed, and invalid data prefetching is avoided.

[0076] This embodiment discloses a data reading method, the flowchart of which is as follows: Figure 4 As shown, it includes:

[0077] Step S401: Obtain the target access request of the target application;

[0078] Step S402: Obtain the target application identifier from the target access request. The target application identifier corresponds to the target application.

[0079] Step S403: Compare the target application identifier with several historical application identifiers, where each historical application identifier corresponds to a historical access feature set within the historical access feature set.

[0080] Step S404: In response to the target application identifier matching the first historical application identifier among several historical application identifiers, determine that the target access request satisfies the first prefetch matching condition, obtain the target access feature set matching the target application from the historical access feature set, the historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively, each historical access feature set includes access parameters of the historical access request sequence of the corresponding application, and the historical access request sequence includes multiple historical access requests.

[0081] Step S405: Based on the target access feature set, generate a target access request sequence, which includes the target access request and multiple predicted access requests following the target access request.

[0082] Step S406: Read data based on the target access request sequence.

[0083] When the target access request meets the prefetch matching conditions, the target access feature set matching the target application is obtained from the historical access feature set in order to generate the target access request sequence, and the data is prefetched based on the target access request sequence in order to improve the data reading efficiency.

[0084] Specifically, the target access request satisfies the prefetch matching condition, which can be defined as follows: satisfying the first prefetch matching condition, namely: obtaining the target application identifier in the target access request, the target application identifier corresponding to the target application; comparing the target application identifier with several historical application identifiers, the historical application identifiers respectively corresponding to each historical access feature set in the historical access feature set; and determining that the target access request satisfies the first prefetch matching condition in response to the target application identifier matching the first historical application identifier among the several historical application identifiers.

[0085] The data reading method disclosed in this embodiment is based on a data access accelerator that obtains the target access request output by the target application from the system bus. Then, the target access request is parsed to extract the target application identifier ASID, that is, to determine the unique identifier of the target application that outputs the target access request.

[0086] The target application identifier (ASID) can be assigned by the software layer when constructing the target access request and written into a specific field of the request frame. This specific field can be a reserved field or a custom field of the request frame. When parsing the target access request, the specific field can be identified and the identifier value in the specific field can be extracted to determine the target application identifier (ASID).

[0087] The Target Application Identifier (ASID) is used to distinguish different application services. The ASID can be in numeric, alphanumeric, or a combination of numbers and letters. Taking the numeric ASID as an example: the range of the ASID can be 0 to 1023, indicating that the system supports a maximum of 1024 different application services for accelerated prefetching. For example, when application A starts, the software layer assigns it ASID 1; when application B starts, it assigns it ASID 2, and so on.

[0088] After obtaining the target application identifier ASID from the target access request, it is also necessary to obtain multiple historical application identifiers and compare the target application identifier ASID with each of the multiple historical application identifiers to determine whether the target application identifier ASID matches the first historical application identifier among the multiple historical application identifiers.

[0089] The process of obtaining historical application identifiers can be as follows: Since a set of historical access features is stored in advance, and the set of historical access features includes multiple sets of historical access features corresponding to multiple applications, the application identifier of each application in the set of historical access features can be determined, and these application identifiers can be identified as historical application identifiers, that is, the historical application identifiers of historical applications stored in the historical records.

[0090] Alternatively, the data access accelerator may store not only a set of historical access features but also a list of application identifiers. In this case, historical application identifiers can be obtained directly from the application identifier list. This application identifier list stores multiple historical application identifiers, each corresponding to a specific set of historical access features in the set of historical access features. That is, each identifier in the application identifier list is associated with a set of historical access features. When an application identifier exists in this application identifier list, it indicates that the historical access feature set records the historical access pattern of the application corresponding to that application identifier.

[0091] To determine whether a first historical application identifier matching the target application identifier ASID exists among multiple historical application identifiers, a sequential search or a hash search can be used. Other methods can also be employed. For example, if the application identifier list contains historical application identifiers {1, 3, 5, 7}, corresponding to the historical access feature sets of applications A, C, E, and G respectively, and the data access accelerator finds a match in the list when the target application identifier is 3, then the existence of a first historical application identifier among the multiple historical application identifiers is confirmed. However, if the target application identifier is 2, no match can be found, indicating that the first historical application identifier does not exist among the multiple historical application identifiers.

[0092] If the target application identifier ASID matches the first historical application identifier among multiple historical application identifiers, it is determined that the target access request meets the first prefetch matching condition. At this time, it can be determined that the target application has initiated an access request in the data access accelerator and been recorded. The data access accelerator has stored the historical access feature set corresponding to the target application.

[0093] At this point, the data access accelerator determines that the currently received target access request meets the first prefetch matching condition. It can generate a target access request sequence based on the historical access feature set corresponding to the target application, so as to read data based on the target access request sequence, complete the data prefetching, and improve the data acquisition efficiency.

[0094] like Figure 5The diagram shows the processing flow of the data access accelerator corresponding to the data reading method disclosed in this embodiment. It includes a main controller and a data access accelerator. The main controller includes two queues: a sending queue and a receiving queue. These two queues are channels for I / O (input / output) interaction between software and hardware. The software puts the access request into the sending queue, and the hardware puts the completion information into the receiving queue to notify the software after completing the data reading. Here, the software refers to the driver program at the bottom layer of the computer system, and the hardware refers to the main controller. The data access accelerator may include a parser, a selector, a sequence generator, and a memory. The memory is used to store the application identifier list and the historical access feature set corresponding to each application. When the target application starts, it outputs an I / O request, which is stored in a sending queue. Then, the parser in the data access accelerator accesses the request from the sending queue and parses the target application identifier corresponding to the access request. The target application identifier is then sent to the selector, along with a list of application identifiers stored in memory. The selector determines whether a first historical application identifier matching the target application identifier is stored in the application identifier list. If not, the result of not having a first historical application identifier in the application identifier list is directly sent to the main controller. If it exists, the target access feature set corresponding to the first historical application identifier is read from memory and sent to the sequence generator. The sequence generator can then generate a target access request sequence based on the target access feature set and transmit the target access request sequence to the main controller. The main controller can then prefetch the data corresponding to each access request in the target access request sequence, achieving data prefetching.

[0095] The data reading method disclosed in this embodiment extracts the target application identifier from the currently received target access request and compares it with multiple historical application identifiers in the stored historical access feature set to quickly determine whether the target application has a relevant record in the historical access feature set. This application identifier-based matching mechanism limits the scope of data pre-reading to achieve the purpose of acceleration to a specific application set, avoids the waste of resources caused by indiscriminate pre-fetching, ensures that the pre-fetching operation is performed on applications with historical access feature sets, and improves the accuracy and effectiveness of pre-fetching.

[0096] This embodiment discloses a data reading method, the flowchart of which is as follows: Figure 6 As shown, it includes:

[0097] Step S601: Obtain the target access request of the target application;

[0098] Step S602: Obtain the target application identifier from the target access request. The target application identifier corresponds to the target application.

[0099] Step S603: Compare the target application identifier with several historical application identifiers, where each historical application identifier corresponds to a historical access feature set within the historical access feature set.

[0100] Step S604: In response to the target application identifier matching the first historical application identifier among a plurality of historical application identifiers, determine that the target access request satisfies the first prefetch matching condition, and determine the target access feature set corresponding to the first historical application identifier;

[0101] Step S605: Compare the target application identifier of the target access request with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set;

[0102] Step S606: In response to the target application identifier of the target access request being matched with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set, it is determined that the target access request satisfies the second prefetch matching condition. A target access request sequence is generated based on the target access feature set. The target access request sequence includes the target access request and multiple predicted access requests following the target access request.

[0103] Step S607: Read data based on the target access request sequence.

[0104] When the target access request meets the prefetch matching conditions, the target access feature set matching the target application is obtained from the historical access feature set in order to generate the target access request sequence, and the data is prefetched based on the target access request sequence in order to improve the data reading efficiency.

[0105] Specifically, the target access request satisfying the prefetch matching condition can be defined as follows: the target access request satisfies both the first and second prefetch matching conditions. For the target access request to satisfy the second prefetch matching condition, the process can be further defined as follows: in response to the target application identifier matching the first historical application identifier, a target access feature set corresponding to the first historical application identifier is determined; the target application identifier of the target access request is compared with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set; in response to the target application identifier of the target access request matching the request identifier corresponding to the first request in the historical access request sequence in the target access feature set, it is determined that the target access request satisfies the second prefetch matching condition.

[0106] The data access accelerator receives a target access request from a target application, extracts the target application identifier from the request, and compares it with several pre-stored historical application identifiers. If the target application identifier matches a first historical application identifier, the accelerator determines that the target access request meets a first prefetch matching condition, meaning the target application has a historical record in the data access accelerator. When a recorded application is restarted, the accelerator detects that the first access request from that application should have the same characteristics as the first request in the historical record, thus triggering subsequent batch prefetching, i.e., determining whether a second prefetch matching condition is met.

[0107] When it is determined that the target access request satisfies the first prefetch matching condition, a target access feature set corresponding to the first historical application identifier that matches the target application identifier is determined from the historical access feature set. This target access feature set contains the access parameters corresponding to each request in multiple historical request sequences generated by the target application during its historical operation. Then, the target application identifier is compared with the request identifier corresponding to the first request in each historical request sequence in the target access feature set to determine whether the target access request matches the first request of a certain historical request sequence in the target access feature set. If it is determined that the target access request matches the first request of a certain historical request sequence in the target access feature set, then it can be determined that the target access request satisfies the second prefetch matching condition.

[0108] by Figure 3 Taking this as an example, if it is determined that the target application identifier of the target access request matches the identifier of application 1, then it is determined that... Figure 3 The target access feature set corresponding to application 1 is defined, and the target access feature set of application 1 includes request sequence 11 and request sequence 12. The request identifier of the first request (request 111) in request sequence 11 and the request identifier of the first request (request 121) in request sequence 12 are determined. The target application identifier is compared with the request identifier of request 111 and the target application identifier is compared with the request identifier of request 121 to determine whether they match. If the target application identifier is determined to match the request identifier of request 111, it can be determined that the target access request satisfies the second prefetch matching condition. At the same time, it can be predicted that the target application is currently requesting request sequence 11.

[0109] Specifically, a flag can be set for each request in each historical access request sequence within the target access feature set. This flag indicates the sequence number of each request within its corresponding historical access request sequence, i.e., it determines which request is in the sequence. Alternatively, the flag can be set only at the first request in each historical access request sequence, indicating that the request is the first request in its corresponding historical access request sequence. The flag can be used to determine the first request in each historical access request sequence and the corresponding request identifier, allowing for further comparison of the target application identifier with the request identifier corresponding to the first request. Alternatively, the first request in each historical access request sequence can be determined in other ways, such as storing each historical access request sequence according to the order of the requests, so that the first request in each historical access request sequence can be determined directly by its storage location.

[0110] After determining that the target access request meets the second prefetch matching condition, a target access request sequence needs to be generated based on the target access feature set. Specifically, the target access request sequence can be generated based on the matching feature set in the target access feature set. The matching feature set is a set of features consisting of the access parameters corresponding to each request in the historical access request sequence where the request identifier of the first request in the target access feature set matches the target application identifier. Continuing with the example above: if the target application identifier matches the request identifier of request 111, then the access parameters corresponding to each request in request sequence 11 containing request 111 are determined, i.e.: Access parameters 111, 112, and 113 form a feature set, which is the matching feature set. A target access request sequence is generated based on this matching feature set. Specifically, request 111 is generated based on access parameter 111, request 112 is generated based on access parameter 112, and request 113 is generated based on access parameter 113. Requests 111, 112, and 113 are combined in sequence to obtain request sequence 11, which is the target access request sequence.

[0111] Furthermore, the target application identifier involved in this embodiment can be an identifier used to characterize the target access request output by the target application; that is, a single target application identifier can identify both the target application and the target access request. Alternatively, the target application identifier consists of two parts: one part is the application identifier of the target application, used to identify the target application, and the other part is the identifier of the target access request, used to identify the target access request. If the target application identifier is a single identifier, in this embodiment, this single identifier can be compared with both historical application identifiers and the request identifier corresponding to the first request. If the target application identifier consists of two parts, when comparing with historical application identifiers, the comparison is achieved through the application identifier in the target application identifier; when comparing with the request identifier of the first request, the comparison is achieved through the identifier of the target access request.

[0112] The data reading method disclosed in this embodiment compares the target application identifier of the currently received target access request with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set to accurately determine whether the target access request is the first request in the historical access request sequence. Only when it is confirmed that the currently received target access request is at the beginning of the request sequence, i.e. the first request, is the generation of the target access request sequence based on the target access feature set triggered, and data prefetching is performed to avoid prefetching data errors caused by sequence misalignment, thus ensuring the accuracy and integrity of the prefetched data.

[0113] This embodiment discloses a data reading method, the flowchart of which is as follows: Figure 7 As shown, it includes:

[0114] Step S701: Obtain the target access request of the target application;

[0115] Step S702: Obtain the target application identifier from the target access request. The target application identifier corresponds to the target application.

[0116] Step S703: Compare the target application identifier with several historical application identifiers, where each historical application identifier corresponds to a historical access feature set within the historical access feature set.

[0117] Step S704: In response to the target application identifier matching the first historical application identifier among a plurality of historical application identifiers, determine that the target access request satisfies the first prefetch matching condition, and determine the target access feature set corresponding to the first historical application identifier;

[0118] Step S705: Compare the target application identifier of the target access request with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set;

[0119] Step S706: In response to the target application identifier of the target access request being matched with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set, it is determined that the target access request meets the second prefetch matching condition, and the key access parameters of the target access request are determined.

[0120] Step S707: Compare the key access parameters with the key access parameters in the access parameters of the first request;

[0121] Step S708: In response to the key access parameter matching with the key access parameter in the access parameter of the first request, determine that the target access request satisfies the third prefetch matching condition, and generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and multiple predicted access requests after the target access request.

[0122] Step S709: Read data based on the target access request sequence.

[0123] When the target access request meets the prefetch matching conditions, the target access feature set matching the target application is obtained from the historical access feature set in order to generate the target access request sequence, and the data is prefetched based on the target access request sequence in order to improve the data reading efficiency.

[0124] Specifically, the target access request satisfying the prefetch matching condition can be defined as follows: the target access request satisfies the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition. For the target access request to satisfy the third prefetch matching condition, the specific steps are as follows: in response to the target application identifier of the target access request being matched with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set, the key access parameters of the target access request are determined; the key access parameters are compared with the key access parameters in the access parameters of the first request; in response to the key access parameters being matched with the key access parameters in the access parameters of the first request, it is determined that the target access request satisfies the third prefetch matching condition.

[0125] The data access accelerator receives the target access request output by the target application, extracts the target application identifier from the target access request, and compares it with multiple pre-stored historical application identifiers to determine that the first prefetch matching condition is met. Further, it compares the target application identifier of the currently received target access request with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set to determine that the second prefetch matching condition is met, that is, the currently received target access request is the first request in a certain historical access request sequence corresponding to the target application.

[0126] After determining that the second prefetch matching condition is met, the data access accelerator extracts key access parameters from the currently received target access request, and compares the key access parameters with the key access parameters in the access parameters of the first request. When a match is found, the third prefetch matching condition can be determined to be met.

[0127] Key access parameters may include: page address, page offset, and data length. These parameters precisely describe the location and size of the data requested by the current target access request in the storage device. The page address is used to identify the physical page where the requested data is located, the page offset is used to accurately locate the starting operation position of the requested data within the page, and the data length indicates the amount of data read in this request.

[0128] Key access parameters are at least a portion of the access parameters. In addition to page address, page offset, and data length, access parameters may also include: a sequence number indicating that the current access request is the first access request in the target access request sequence; and may also include: reserved extended information. For example... Figure 8 The diagram shown is a schematic of the access parameters corresponding to each request in a historical access feature set disclosed in this embodiment, including: reserved extension information, data length, page offset, page address and sequence number identifier, and the numerical value corresponding to each access parameter.

[0129] The historical access feature set is pre-stored in the Static Random Access Memory (SRAM) inside the data access accelerator. This SRAM is divided into multiple storage areas, each corresponding to an application identifier (ASID). Each application identifier's storage area has a set number of slots (SLOTs), and each slot stores the access parameters corresponding to a historical access request. The SRAM is divided into storage areas according to the application identifier. Taking the storage area corresponding to application identifier ASID0 as an example, this area has 1024 slots (SLOT0 to SLOT1023), each occupying 128 bits of storage space to store the complete access parameters corresponding to a historical access request. The access parameters in each slot are divided according to bit fields, including: the sequence number identifier in the bit field [31,0], used to identify the current request's position in its sequence, or to identify whether the current request is the first request in the request sequence; it may also include: the page address in the bit field [63,32], used to identify the physical page where the requested data is located; it may also include: the page offset in the bit field [75,64], used to accurately locate the starting operation position of the requested data within the page; it may also include: the data length in the bit field [87,76], used to indicate the amount of data read in this request; and it may also include: reserved extension information in the bit field [127,88], used to reserve extension functions. In the storage area corresponding to each application identifier, each slot stores the access parameters of each historical access request in the historical access request sequence corresponding to that application in the order of the request sequence.

[0130] The size of the static random access memory (SRAM) inside the data access accelerator is determined based on the maximum number of application identifiers and the maximum number of slots corresponding to each application identifier. Specifically, it can be: 128 is in bits. This represents the maximum number of application identifiers, which can be up to 1024. This represents the maximum number of slots, which can be up to 1024. and When all configurations are at maximum, the storage space occupied is 16MB, or 128 / 8×1024×1024. Compared to the software prefetching scheme, which requires maintaining a 4KB×1024×102=4GB cache database in memory, this embodiment stores the historical access feature set in a compact bit-encoded manner in the static random access memory inside the data access accelerator, saving memory space. At the same time, since the split access requests are all generated directly by the hardware into complete sequences and generated at once, without needing to be passed through multiple software stacks one after another, the performance is greatly improved.

[0131] Due to limited memory space, only a certain number of IDs and slots can be stored. If the number of sequences to be split exceeds the number of slots, for example, there are 2000 sub-requests, but the historical features are concentrated, with only 1024 sub-requests, data for sub-requests 1025 and beyond cannot be prefetched. However, prefetching the earlier parts can improve efficiency.

[0132] Taking a hard drive as an example of the accessed storage device, the above access parameters correspond to the physical storage structure of the hard drive. Specifically, the page address corresponds to the sector number on the hard drive, used to identify the sector where the requested data is located; the page offset corresponds to the offset within the sector, used to precisely specify the starting position of the data within the sector; and the data length corresponds to the length of the data to be read in this request, used to indicate the amount of data to be read starting from that initial position within the sector. These parameters are stored in the slots of static random access memory (SRAM). However, the parameters describe the physical location of the data on the hard drive, enabling the data access accelerator to pre-construct a complete access request based on the parameters stored in SRAM and accurately read the corresponding data from the hard drive.

[0133] After obtaining the key access parameters of the target access request, it is also necessary to determine the key access parameters in the access parameters of the first request that matches the target application identifier in the target access feature set. Then, the key access parameters of the target access request are compared with those of the first request to determine if they match. Specifically, this involves determining if the page address corresponding to the target access request matches the page address of the first request, if the page offset corresponding to the target access request matches the page offset of the first request, and if the data length corresponding to the target access request matches the data length of the first request. Only when the page address, Page Only when both the offset and the data length match can it be determined that the target access request meets the third prefetch matching condition. If either parameter does not match, it is determined that the target access request does not meet the third prefetch matching condition.

[0134] When it is determined that the target access request meets the third prefetch matching condition, the target access request sequence needs to be generated based on the target access feature set. Specifically, the target access request sequence needs to be generated based on the matching feature set in the target access feature set. The matching feature set is a feature set composed of the access parameters corresponding to each request in the historical access request sequence that matches the request identifier of the first request in the target access feature set with the target application identifier.

[0135] The data reading method disclosed in this embodiment compares the key access parameters of the currently received target access request with the key access parameters of the first request in the historical record. Based on application identifier matching and the first request matching in the request sequence, it further verifies whether the key access parameters of the current target access request are consistent with those in the historical record. This triple matching mechanism ensures that the data access accelerator only starts the pre-reading process when the access parameters are completely matched. This avoids pre-fetching errors caused by differences in storage location or data volume, ensures the accuracy of subsequent request predictions, and improves the accuracy and availability of pre-fetched data, avoiding problems such as bandwidth waste caused by invalid pre-fetching.

[0136] This embodiment discloses a data reading method, the flowchart of which is as follows: Figure 9 As shown, it includes:

[0137] Step S901: Obtain the target access request of the target application;

[0138] Step S902: Obtain the target application identifier from the target access request. The target application identifier corresponds to the target application.

[0139] Step S903: Compare the target application identifier with several historical application identifiers, where each historical application identifier corresponds to a historical access feature set within the historical access feature set.

[0140] Step S904: In response to the target application identifier matching the first historical application identifier among a plurality of historical application identifiers, determine that the target access request satisfies the first prefetch matching condition, and determine the target access feature set corresponding to the first historical application identifier;

[0141] Step S905: Compare the target application identifier of the target access request with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set;

[0142] Step S906: In response to the target application identifier of the target access request being matched with the request identifier corresponding to the first request in the historical access request sequence in the target access feature set, it is determined that the target access request meets the second prefetch matching condition, and the key access parameters of the target access request are determined.

[0143] Step S907: Compare the key access parameters with the key access parameters in the access parameters of the first request;

[0144] Step S908: In response to the key access parameter matching with the key access parameter in the access parameter of the first request, determine that the target access request satisfies the third prefetch matching condition, and generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and multiple predicted access requests after the target access request.

[0145] Step S909: Read data based on the target access request sequence;

[0146] Step S910: In response to the target access request not satisfying any one of the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition, data is read based on the content of the target access request.

[0147] When the target access request meets the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition, the target access feature set matching the target application is obtained from the historical access feature set in order to generate the target access request sequence, and the data is prefetched based on the target access request sequence in order to improve the data reading efficiency.

[0148] Furthermore, if the target access request does not meet any of the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition, data is read based on the content of the target access request.

[0149] In this embodiment, the data access accelerator uses three levels of matching conditions to determine whether a target access request can trigger prefetch acceleration: a first prefetch matching condition, a second prefetch matching condition, and a third prefetch matching condition. This ensures the accuracy of the data read in advance after prefetch acceleration is triggered. In various cases, these prefetch matching conditions may not all be met. If any prefetch matching condition is not met, the prefetch acceleration process disclosed in this embodiment is not executed, nor is the judgment of whether other prefetch matching conditions are met. Instead, the conventional process is followed, and the target access request is directly passed through to the main controller. The main controller then reads the corresponding data based on the target access request. In this case, the data reading method disclosed in this embodiment only passes through the target access request without performing any other processing.

[0150] If the target application's access request does not meet the first prefetch matching condition, it indicates that the target application identifier is not present in the multiple pre-stored historical application identifiers. This means that the target application is running for the first time, or that the information recorded during the previous run of the target application has been deleted and is not stored in the historical access feature set. For example, when a user installs and launches an application that has never been run before, such as a newly downloaded game, when the first access request of the application arrives at the data access accelerator, the parser extracts the target application identifier from it, such as the target application identifier being 15. Then, it searches in the pre-stored application identifier list. Since the application has never been run before, the identifier 15 is not present in the application identifier list, thus it can be determined that the first prefetch matching condition is not met.

[0151] If the target access request of the target application does not meet the second prefetch matching condition, it indicates that the target access request is not the first request in the request sequence, or that the request identifier of the first request recorded in the historical access feature set is abnormal. For example, if a recorded application is running, and the target application identifier of the application is 5, and the target access request of the application reaches the data access accelerator, and the historical access feature set includes the historical access feature set with the historical application identifier 5, then the first prefetch matching condition is met; however, if the target application identifier 5 is inconsistent with the request identifier of the first request in each historical access request sequence in the historical access feature set, then it can be determined that the second prefetch matching condition is not met.

[0152] If the target application's access request does not meet the third prefetch matching condition, it indicates that the key access parameters are inconsistent with the key access parameters of the first request. This may be due to situations such as the target application identifier being reused, leading to a mismatch between the access parameters recorded in the historical access feature set and the identifier. For example, taking the target application identifier as an example, application identifier 10 originally corresponded to application A, but application A was deleted from the historical application identifiers by the user. Therefore, application identifier 10 was recycled and assigned to a newly installed application B. At this time, application identifier 10 was re-recorded in the historical application identifiers. When application B is launched for the first time, its first access request carries the target application identifier 10. Since application identifier 10 exists in the historical application identifiers and the historical access feature set, the first prefetch matching condition is met. The target application identifier 10 corresponds to the request identifier of a certain historical access request in the corresponding historical access feature set, so the second prefetch matching condition is also met. However, the key access parameters of the target access request of application B are inconsistent with the key access parameters of the first request of application A in the historical feature set, so the third prefetch matching condition is not met.

[0153] The first prefetch matching condition is to determine whether the application identifier matches. In this embodiment, it is necessary to first determine whether the target application is an application that has been recorded in the historical access feature set. If there is no record matching the target application in the historical access feature set, it indicates that the target application is making a request for the first time and there is no relevant historical record in the data access accelerator. Therefore, there is no need to perform the second and third prefetch matching conditions. Therefore, the first prefetch matching condition must be performed first. Only after the first prefetch matching condition is met will the subsequent judgment be performed.

[0154] The second prefetch matching condition is the judgment of whether the first request in the request sequence matches. It is only executed on the basis of satisfying the first prefetch matching condition. After confirming that there is a record matching the target application stored in the historical access feature set, the data access accelerator further judges whether the currently received target access request corresponds to the first request in the historical access request sequence. If the identifier of the target request does not match the first request in the historical access request sequence, it means that the target request is not the first request in the historical access request sequence and subsequent requests cannot be predicted. Therefore, there is no need to continue to judge the third prefetch matching condition. The judgment of the third prefetch matching condition will only be executed after the second prefetch matching condition is matched.

[0155] The third prefetch matching condition is the judgment of whether the key access parameters match. It is only executed on the basis of satisfying the first prefetch matching condition and the second prefetch matching condition. The data access accelerator will only further judge whether the key access parameters of the target request match the key access parameters of the first request in the historical access request sequence after confirming that there is a history record of the target application in the historical access feature set and that the target request is the first request in the historical access request sequence. If they do not match, there is no need to start the prefetch process.

[0156] Therefore, the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition are judged sequentially. The second prefetch matching condition will be judged only if the first prefetch matching condition is satisfied, and the third prefetch matching condition will be judged only if the second prefetch matching condition is satisfied. Correspondingly, if the first prefetch matching condition is not satisfied, the second and third prefetch matching conditions do not need to be judged, and if the second prefetch matching condition is not satisfied, the third prefetch matching condition does not need to be judged.

[0157] Furthermore, the data reading method disclosed in this embodiment may also include:

[0158] In response to the target access request not meeting the first prefetch matching condition, a historical access feature set corresponding to the target application identifier is added to the historical access feature set, and the access parameters in the historical access feature set corresponding to the target application identifier are determined based on the target access request.

[0159] When it is determined that the target access request does not meet the first prefetch matching condition, i.e., no historical application identifier matching the target application identifier has been pre-stored, the data access accelerator allocates a new storage entry for the target application identifier to record the identity information of the target application, i.e., stores the target application identifier. Specifically, the target application identifier is added to the application identifier list used to store historical application identifiers in the data access accelerator, and a corresponding location and storage space are allocated for the target application identifier in the historical access feature set for subsequent storage of the historical access feature set of the target application.

[0160] Furthermore, when allocating a new storage entry for a target application identifier, the memory in the data access accelerator used to store historical access feature sets may not have any free storage entries for storing the target application identifier's information. In this case, the relevant information of an application identifier can be determined from the memory and deleted. Based on the access frequency in the historical access feature set, the application identifier with the lowest access frequency can be selected from the relevant information of multiple application identifiers and its relevant information can be deleted. Alternatively, the application identifier with the longest unaccessed duration can be selected and its relevant information can be deleted, thereby obtaining a free storage entry to store the target application identifier's information. Or, other methods can be used, such as a combination of multiple algorithms. For example, the records of multiple applications with usage frequencies below a certain threshold can be determined from the usage frequency of the feature set corresponding to each application, and the record of the application with the longest unaccessed duration can be selected and its relevant information deleted. Therefore, it is also necessary to record the number of times each feature set is used and the time of the last use so as to obtain a free storage entry based on the number of times it is used and the time of use.

[0161] The data access accelerator parses the currently received target access request, extracts the value of the access parameter corresponding to the target access request, and stores the extracted access parameter value in the location corresponding to the target application identifier.

[0162] In addition, since the currently received target access request is the first request in the request sequence corresponding to the target application, the data access accelerator only records the value of the access parameter of the first request at the position corresponding to the first request in the historical access feature set. The other positions in the historical access feature set corresponding to the target application are used to record the value of the access parameter of the subsequent requests one by one when the target application continues to make requests, thereby gradually constructing the value of the access parameter corresponding to each request in the complete request sequence.

[0163] When a target application initiates a request for the first time, the data access accelerator adds the target application's identification information to the historical access feature set, extracts the values ​​of access parameters based on the current request, and stores them at the corresponding positions in the historical access feature set. This process does not require pre-analyzing and configuring the request sequence, nor does it require maintaining a large cache database in memory. Instead, it completes the acquisition and storage of requests in real time during the request reception process, providing a data foundation for the pre-reading of subsequent identical requests.

[0164] Furthermore, the data reading method disclosed in this embodiment may also include:

[0165] In response to the target access request not meeting the second or third prefetch matching condition, the access parameters in the historical access feature set corresponding to the target application identifier in the historical access feature set are updated based on the target access request.

[0166] When it is determined that the target access request does not meet the second prefetch matching condition, the target access request is not the first request in the historical access request sequence. In this case, the target access request may be a subsequent request in the current startup process of the target application, or it may be an abnormal request identifier of the first request in the historical access request sequence. The above situations usually occur before the learning phase is over, or when the application version is updated. At this time, it is necessary to determine the position of the target access request in the historical access request sequence, that is, its corresponding sequence number in the request sequence, such as the second request, or the third request, etc., and update the access parameters of the target access request to the position corresponding to that sequence number in the historical access request sequence to achieve the update of access parameters.

[0167] When it is determined that the target access request does not meet the third prefetch matching condition, the target application's target access request is the first request in the historical access request sequence, but its key access parameters are inconsistent with the key access parameters of the first request in the historical access request sequence. This situation may be due to the target application identifier being reused by other applications, but the historical access feature set corresponding to that target application identifier has not been updated; or, the startup process has changed after the same application is upgraded; or, the same application has different startup path branches due to different configurations, etc. In this case, it is necessary to determine the historical access feature set that matches the target application identifier in the historical access feature set, delete the data in the historical access feature set, and update the data corresponding to the historical access feature set according to the current target access request. The data corresponding to the historical access feature set may include the historical access request sequence and the access parameters corresponding to each request in each historical access request sequence.

[0168] When the data access accelerator detects that the key access parameters of the target access request are inconsistent with the key access parameters of the first request in the historical access request sequence, it automatically updates the corresponding data in the historical access request sequence based on the current target access request. This ensures that the historical access feature set stored internally by the data access accelerator is always consistent with the latest access parameters of the target application, avoiding the problem of invalid prefetching based on outdated data and guaranteeing the accuracy of data prefetching.

[0169] The data reading method disclosed in this embodiment immediately stops the prefetching process when any prefetching matching condition is not met, and passes the current target access request to the main controller for execution according to the normal process. This fallback mechanism ensures that the target application's target access request can still be responded to normally even when the prefetching matching condition is not met, avoiding reading errors or system function interruptions caused by forced prefetching, and ensuring the reliability of data reading and business continuity.

[0170] This embodiment discloses a data access accelerator, the structural diagram of which is shown below. Figure 10 As shown, it includes:

[0171] Parser 1001, processor 1002 and sequence generator 1003.

[0172] The parser 1001 is used to obtain the target access request of the target application and parse the target access request to obtain the parsing result.

[0173] The processor 1002 is used to respond to the parsing result indicating that the target access request meets the prefetch matching condition, and to obtain the target access feature set matching the target application from the historical access feature set. The historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application. The historical access request sequence includes multiple historical access requests.

[0174] The sequence generator 1003 is used to generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and multiple predicted access requests following the target access request, so as to read data based on the target access request sequence.

[0175] Furthermore, the data access accelerator disclosed in this embodiment may also include:

[0176] The first memory is used to store the set of historical access features.

[0177] The first memory is located inside the data access accelerator and is directly connected to the parser 1001, processor 1002 and sequence generator 1003. This facilitates local and rapid local matching of historical features, reduces external memory access overhead, improves real-time performance, and reduces system resource consumption.

[0178] The first memory can be: Static Random Access Memory (SRAM), which has the characteristics of fast access speed, no need for refreshing, and relatively low power consumption, and can meet the needs of data access accelerator to perform high-frequency, low-latency reading of historical access feature sets; Alternatively, the first memory can also be: Register File, which has extremely low access latency and wide read / write bandwidth, and is suitable for scenarios with high access speed requirements and small historical access feature sets.

[0179] The storage capacity of the first memory can be configured according to the maximum number of application identifiers and the maximum number of slots for each application identifier, such as 16MB.

[0180] In practical applications, the type and capacity configuration of the first memory can be flexibly determined based on system performance requirements, area and power consumption constraints, and application scenario characteristics.

[0181] The processor 1002 includes at least: a selector for determining whether a target access request meets the prefetch matching conditions, and an acquisition module for obtaining a target access feature set that matches the target application from a historical access feature set.

[0182] The data access accelerator disclosed in this embodiment is implemented based on the data reading method disclosed in the above embodiment, and will not be described again here.

[0183] The data access accelerator disclosed in this embodiment reads the corresponding target access feature set directly from the historical access feature set when the target access request meets the prefetch matching conditions, and generates a complete target access request sequence at once based on the target access feature set. This enables data reading to be performed directly based on each access request in the target access request sequence, thereby improving the efficiency of data reading and enhancing the performance of the computer system.

[0184] This embodiment discloses an electronic device, the schematic diagram of which is shown below. Figure 11 As shown, it includes:

[0185] The request terminal 1101, the second memory 1102, and the data access accelerator 1103.

[0186] Among them, the request end 1101 is used to output the target access request of the target application;

[0187] The second memory 1102 is used to store historical access feature sets, which include multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application, and the historical access request sequence includes multiple historical access requests.

[0188] The data access accelerator 1103 is used to obtain the target access request output by the requesting end. In response to the target access request satisfying the prefetch matching condition, it obtains the target access feature set matching the target application from the historical access feature set. Based on the target access feature set, it generates a target access request sequence, which includes the target access request and multiple predicted access requests following the target access request. Data is read based on the target access request sequence.

[0189] The second memory 1102 can be located inside the data access accelerator 1103, that is, the historical access feature set is stored inside the data access accelerator 1103, and no additional memory is required for separate storage.

[0190] The electronic device disclosed in this embodiment is implemented based on the data reading method disclosed in the above embodiments, and will not be described again here.

[0191] The electronic device disclosed in this embodiment reads the corresponding target access feature set directly from the historical access feature set when the target access request meets the prefetch matching conditions, and generates a complete target access request sequence at once based on the target access feature set. This enables data reading to be performed directly based on each access request in the target access request sequence, thereby improving the efficiency of data reading and enhancing the performance of the computer system.

[0192] This application also provides a readable storage medium storing a computer program, which is loaded and executed by a processor to implement the steps of the above data reading method. The specific implementation process can be referred to the description of the corresponding part of the above embodiments, and will not be repeated in this embodiment.

[0193] This application also proposes a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in various optional implementations of the above-described data reading method. Specific implementation processes can be referred to the descriptions of the corresponding embodiments above, and will not be repeated here.

[0194] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0195] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0196] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0197] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A data reading method, comprising: Obtain the target application's target access request; In response to the target access request satisfying the prefetch matching condition, a target access feature set matching the target application is obtained from the historical access feature set. The historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application. The historical access request sequence includes multiple historical access requests. Based on the target access feature set, a target access request sequence is generated, the target access request sequence including the target access request and multiple predicted access requests following the target access request; Data is read based on the target access request sequence.

2. The method according to claim 1, wherein the method for determining whether the target access request satisfies the prefetch matching condition includes: Obtain the target application identifier from the target access request, wherein the target application identifier corresponds to the target application; The target application identifier is compared with several historical application identifiers, wherein each historical application identifier corresponds to a different historical access feature set within the historical access feature set. In response to the target application identifier matching a first historical application identifier among the plurality of historical application identifiers, it is determined that the target access request satisfies a first prefetch matching condition.

3. The method according to claim 2, wherein the method for determining whether the target access request satisfies the prefetch matching condition further includes: In response to the matching of the target application identifier with the first historical application identifier, a target access feature set corresponding to the first historical application identifier is determined; The target application identifier of the target access request is compared with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set; In response to the target application identifier of the target access request matching the request identifier corresponding to the first request in the historical access request sequence of the target access feature set, it is determined that the target access request satisfies the second prefetch matching condition.

4. The method according to claim 3, wherein the method for determining whether the target access request satisfies the prefetch matching condition further includes: In response to the target application identifier of the target access request being matched with the request identifier corresponding to the first request in the historical access request sequence of the target access feature set, the key access parameters of the target access request are determined. The key access parameters are compared with the key access parameters in the access parameters of the first request; In response to the key access parameter matching the key access parameter in the access parameter of the first request, it is determined that the target access request satisfies the third prefetch matching condition.

5. The method according to claim 4, further comprising: In response to the target access request not satisfying any one of the first prefetch matching condition, the second prefetch matching condition, and the third prefetch matching condition, data is read based on the content of the target access request.

6. The method according to claim 5, further comprising: In response to the target access request not satisfying the first prefetch matching condition, a historical access feature set corresponding to the target application identifier is added to the historical access feature set, and access parameters in the historical access feature set corresponding to the target application identifier are determined based on the target access request.

7. The method according to claim 5, further comprising: In response to the target access request not satisfying the second prefetch matching condition or the third prefetch matching condition, the access parameters in the historical access feature set corresponding to the target application identifier in the historical access feature set are updated based on the target access request.

8. A data access accelerator, comprising: A parser is used to obtain the target access request of the target application and parse the target access request to obtain the parsing result; The processor is configured to, in response to the parsing result indicating that the target access request satisfies the prefetch matching condition, obtain a target access feature set matching the target application from the historical access feature set, wherein the historical access feature set includes multiple historical access feature sets corresponding to multiple applications respectively, each historical access feature set includes access parameters of the historical access request sequence of the corresponding application, and the historical access request sequence includes multiple historical access requests. A sequence generator is used to generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and a plurality of predicted access requests following the target access request, so as to perform data reading based on the target access request sequence.

9. The data access accelerator according to claim 8, further comprising: A first memory is used to store the set of historical access features.

10. An electronic device, comprising: The request side is used to output the target application's target access request; The second memory is used to store historical access feature sets, which include multiple historical access feature sets corresponding to multiple applications respectively. Each historical access feature set includes access parameters of the historical access request sequence of the corresponding application, and the historical access request sequence includes multiple historical access requests. A data access accelerator is used to obtain the target access request output by the requesting end, and in response to the target access request satisfying the prefetch matching condition, to obtain a target access feature set matching the target application from the historical access feature set, and to generate a target access request sequence based on the target access feature set. The target access request sequence includes the target access request and a plurality of predicted access requests following the target access request; and to perform data reading based on the target access request sequence.

Images