Prefetching methods, storage devices, and computer program products

Abstract

This application discloses a prefetching method, storage device, and computer program product. The method includes: after the previous read command ends, constructing a current predictive prefetch command, wherein the start address of the current prefetch data requested by the current predictive prefetch command inherits the end address of the data in the previous read command and has the same data read length as the previous read command; prefetching the current prefetch data according to the current predictive prefetch command and caching it in a data cache; and in response to the current read command, comparing the requested data start address and data read length with the start address and data read length of the current prefetch data, and returning the current actual read data based on the comparison result. This application can achieve efficient sequential read acceleration with minimal memory overhead, improve bandwidth, and bring about read performance improvement.

Description

Technical Field

[0001] This application relates to the field of data reading technology, and in particular to a pre-reading method, storage device, and computer program product. Background Technology

[0002] Data prefetching technology can cache data that the host may request from the storage device from the non-volatile storage medium (such as NAND flash memory) of the storage device into a cache (such as RAM) in advance, thereby hiding the media access latency and improving read performance.

[0003] Depending on the triggering method, data prefetching technology is mainly divided into "notification-based prefetching" and "predictive prefetching". Among them, predictive prefetching autonomously predicts future accesses based on the sequential read pattern of historical read commands (such as address contiguous attributes). It does not require host cooperation and has strong versatility. However, it usually requires a large amount of independent RAM resources to store prefetched data and maintain the prediction state. Therefore, it is difficult to implement in embedded storage devices (such as SSD / eMMC / UFS, etc.) with extremely limited hardware resources (especially RAM), especially in low-cost embedded storage devices. Summary of the Invention

[0004] This application provides a pre-read method, storage device, and computer program product to improve sequential read performance with low resource overhead and high hit rate.

[0005] In a first aspect, embodiments of this application provide a pre-read method applied to an embedded storage device, the pre-read method comprising: After the previous read command is completed, the current predictive read command is constructed. The start address of the data to be read in this predictive read command is inherited from the end address of the data in the previous read command, and has the same data read length as the previous read command. According to the predictive prefetch command, the prefetch data is read in advance and cached in the data cache area; In response to this read command, compare the requested data start address and data read length with the start address and data read length of the current pre-read data, and return the actual data read in this operation based on the comparison result.

[0006] Implementing the embodiments of this application, a predictive read-ahead command is constructed based on the previous read command. Its starting address inherits from the ending address of the previous read command, and its data read length is equal to the data read length of the previous read command, achieving precise tracking of sequential read commands. When the host issues a read command, the address and length are compared, and the actual read data is returned based on the matching result. Using a single read command as the read-ahead object, only the data length of a single read command needs to be cached each time. Thus, without requiring a large independent RAM, efficient and high-hit-rate read-ahead acceleration is achieved with minimal time and space overhead, approaching that of a normal read command.

[0007] In at least one possible implementation, returning the actual data read in this instance based on the comparison result specifically includes: If the comparison results are the same, the data read in this pre-reading will be returned as the data read in this actual reading. If the comparison result is only that the data read length is different, then the actual read data is obtained based on the pre-read data and the actual read data is returned.

[0008] By implementing the embodiments of this application, by distinguishing between the two cases of "complete match" and "different length", the length deviation between the read command issued by the host and the pre-read data can be flexibly handled. Even if the pre-read command cannot completely hit the target, it can still achieve a high hit rate close to that of a normal read command and avoid wasting the pre-read data. This avoids discarding the entire pre-read data due to length mismatch and fully improves the hit rate and utilization of the pre-read data.

[0009] In at least one possible implementation, obtaining the current read data based on the current pre-read data specifically includes: If the length of the pre-read data is greater than the length of the actual read data, then select the actual read data from the pre-read data and return it. If the length of the pre-read data is less than the length of the actual data read, then the difference between the length of the actual data read and the length of the pre-read data is read and combined with the pre-read data to form the actual data read and returned.

[0010] By implementing the embodiments of this application, the precise matching between the pre-read data and the data requested by the actual read command is achieved through interception or supplementary reading. This ensures that the pre-read data can be effectively utilized regardless of whether it is greater than or less than the actual read data, thereby maximizing the benefits of pre-reading.

[0011] In at least one possible implementation, after selecting and returning the currently read data from the currently pre-read data, the method further includes: Clear the data that was not selected in this pre-read data; or After the data for this pre-read is read and cached in the data cache, the following steps are also included: If the predictive read command fails, the read data cached in the data buffer will be cleared.

[0012] By implementing the embodiments of this application, valuable data cache resources are released by timely clearing invalid or unused prefetch data, avoiding cache pollution. Even if the prefetch misses completely or not at all, it will not burden the cache, thus fully ensuring memory utilization efficiency.

[0013] In at least one possible implementation, the current predictive read-ahead command is determined to be invalid under the following conditions: If, after the pre-read data has been read and cached in the data buffer, the received command is not a read command, then the predictive pre-read command is deemed invalid; or If the read command is not received within the preset time, the predictive read command is deemed invalid; or If the comparison result shows that the starting address of the actual read data is different from the starting address of the pre-read data, then the predictive pre-read command is determined to be invalid.

[0014] By implementing the embodiments of this application, and by setting various failure conditions (non-read command, timeout, address mismatch), it is ensured that the pre-read resources will not be occupied ineffectively for a long time, thereby improving the system's high-speed responsiveness and resource utilization.

[0015] In at least one possible implementation, prior to constructing the current read-ahead command, the method further includes: Determine whether the previous read command constitutes a read command with one or more preceding read commands in a contiguous address sequence. If so, trigger the construction of the current predictive read command.

[0016] By implementing the embodiments of this application, pre-reading is triggered only when a sequential read mode is detected, avoiding meaningless pre-reading operations in random read scenarios (random reads are unpredictable because the next data read address and data read length are random), reducing unnecessary background reads and cache usage, and lowering power consumption.

[0017] In at least one possible implementation, after returning the data read in this instance, the method further includes: Construct the next predictive read command. The start address of the read data of the next predictive read command is inherited from the end address of the data of the current read command, and it has the same data read length as the current actual read data.

[0018] By implementing the embodiments of this application, adaptive tracking of the pre-read length is achieved by setting the next pre-read length to the current actual read length. Regardless of the deviation between the current pre-read data length and the data length requested by the host read command, the next pre-read data length will be immediately adjusted to the current actual read data length, thereby quickly converging to the host's true read step size and avoiding accumulated deviations.

[0019] In at least one possible implementation, the pre-read method further includes: When constructing the predictive read-ahead command, the command state is set to read-ahead mode. In read-ahead mode, only data reading and caching are performed, and data transmission is not performed. In response to the read command, the command state is set to transfer mode, in which data reading and data transfer operations are performed.

[0020] By implementing the embodiments of this application, the distinction between dual-state modes (read-ahead mode / transfer mode) allows the same command object to play different roles at different stages, eliminating the need for additional descriptor tables or state machines and reducing firmware complexity. In read-ahead mode, only cached data is not sent; in transfer mode, the cached data is sent to the host. By setting different state parameters, precise distinction and processing of read-ahead data and actual data can be achieved.

[0021] In at least one possible implementation, setting the command state to read-ahead mode specifically includes: setting the command receiving flag of the predictive read-ahead command to a first value; Setting the command status to transmission mode specifically includes setting the command receiving flag of the read command to a second value.

[0022] By implementing the embodiments of this application, state differentiation can be achieved with just one binary bit, resulting in extremely low hardware overhead, making it very suitable for resource-constrained environments for embedded devices.

[0023] In at least one possible implementation, the data cache is a RAM cache shared with read commands.

[0024] In implementing the embodiments of this application, the prefetch data and host read / write commands share the same RAM buffer, eliminating the need for a separate prefetch cache and further reducing memory requirements. When the bus is idle, the previously unused buffer is used for prefetch data storage, achieving prefetching with zero additional RAM overhead.

[0025] In at least one possible implementation, the method further includes: In response to receiving a notification-based read-ahead command, the predictive read-ahead command is not constructed, and the notification-based read-ahead command is executed directly.

[0026] By implementing the embodiments of this application, and by being compatible with notification-based prefetching (such as the CMDQ command of the eMMC protocol), seamless integration into a hybrid command environment that supports both CMDQ and predictive prefetching (such as the non-CMDQ command of the eMMC protocol) can be achieved, enabling the device to automatically select the optimal prefetching strategy based on the command type.

[0027] Secondly, embodiments of this application provide a storage device including a processor and a memory, the memory being coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, causing the processor to perform the steps in the pre-read method as described in the first aspect.

[0028] Thirdly, embodiments of this application provide a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform the steps in the pre-read method as described in the first aspect.

[0029] The beneficial effects of this application are: This application embodiment constructs a predictive read-ahead command based on the previous read command. The starting address of the read-ahead data is inherited from the ending address of the previous read command, and the data read length is equal to the data read length of the previous read command, achieving precise tracking of the sequential read pattern. When the host issues a read command, it compares the address and length, and directly returns the actual read data based on the matching result. This achieves efficient read-ahead acceleration in a lightweight manner, and can be seamlessly integrated into the firmware of existing eMMC embedded storage devices, significantly improving sequential read bandwidth and reducing firmware development costs and power consumption. Attached Figure Description

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

[0031] Figure 1 This is a schematic diagram of existing predictive readout technology.

[0032] Figure 2 This is a flowchart illustrating the pre-read method according to an embodiment of this application.

[0033] Figure 3 This is a schematic diagram of the comparison result processing flow in the pre-reading method of this application embodiment.

[0034] Figure 4 This is a flowchart illustrating a pre-reading method according to another embodiment of this application.

[0035] Figure 5 This is a schematic diagram of the structure of a storage device according to an embodiment of this application. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0037] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0038] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0039] Performance bandwidth is a core metric for storage devices, and the two most important test metrics for measuring bandwidth are sequential reads and sequential writes. To improve sequential read bandwidth, storage vendors use data prefetching technology to cache data in advance. When a host continuously requests data with increasing addresses, reading subsequent data from the NAND flash memory into the cache in advance can significantly reduce response latency. Depending on the triggering type of prefetching, data prefetching technology can generally be divided into "predictive" prefetching and "notification" prefetching. The eMMC 5.1 protocol supports CMDQ and Non-CMDQ read commands. CMDQ command prefetching belongs to "notification" prefetching, while Non-CMDQ command prefetching belongs to "predictive" prefetching. Notification-based read-ahead: Obtain the host command sequence in advance (such as the CMDQ command in the eMMC 5.1 protocol), and perform read-ahead decisions under the known command sequence. The read-ahead hit rate is 100%, and the impact on I / O latency is small. However, since it relies on the host to actively inform the host of the future read command sequence, it has high protocol requirements on the host side. Predictive read-ahead: Based on past read I / O, predict the I / O blocks that will be accessed in the future, and make read-ahead decisions. It requires separate RAM resources, has unstable read-ahead hit rate, and introduces I / O latency issues.

[0040] Implementing read-ahead technology requires accommodating two different read commands, which is extremely difficult in firmware implementation. Firmware vendors typically choose to support only one of them. Please also refer to... Figure 1 , Figure 1 This diagram illustrates how traditional predictive read-ahead technology uses a separate read-ahead buffer (RAM buffer 1) independent of the read / write buffer (RAMBuffer 0) for buffering read-ahead data. The start and end positions of the buffered data are recorded by two pointers: head and tail. When a host read command hits the buffer, the data is sent directly from the read-ahead buffer to the host. Its advantages include the ability to buffer large amounts of data, and the availability of read-ahead data for multiple read commands. However, its disadvantages are also apparent: it requires a large and independent RAM buffer 1 and complex state machine management.

[0041] For small-capacity embedded storage devices (such as SSDs / eMMCs / UFSs), there is usually only tens of KB of on-chip SRAM. The hardware resources are insufficient to support the large independent cache and complex state machine required by traditional predictive read-ahead technology. Therefore, existing embedded devices such as eMMCs generally do not support read-ahead technology or only support CMDQ command read-ahead technology, and cannot support Non-CMDQ command read-ahead acceleration, resulting in poor sequential read performance in scenarios where the host does not support CMDQ or mixed commands.

[0042] Therefore, this application aims to provide a pre-read method for embedded storage devices. Its core lies in abandoning the traditional design of independent RAM buffers and independent pre-read paths. Instead, it uses commands as the pre-read object, and the pre-read data is unique to the current pre-read command. Without requiring a large independent RAM, it utilizes the current read command data bus transmission time and the command interval between read commands for data pre-reading. This achieves efficient sequential read acceleration with minimal memory and time overhead, increasing bandwidth and improving read performance. Please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the pre-read method according to an embodiment of this application. The pre-read method includes: In step S110, after the previous read command ends, a predictive read command is constructed. The start address of the read data requested by the current predictive read command is inherited from the end address of the data in the previous read command, and it has the same data read length as the previous read command.

[0043] Specifically, when the firmware detects a continuous sequential read pattern (e.g., multiple read commands with consecutively increasing start addresses), after the previous read command is processed, the firmware proactively constructs an internal predictive read command. The start address of this command is set to the end address of the previous read command (i.e., the start address of the previous read command + length), and the length is set to the length of the previous read command. For example, if the previous read command read addresses 0x1000~0x2000 (length 0x1000), then the start address of this read command is 0x2000, and the length is 0x1000.

[0044] In step S120, according to the current predictive read command, the current read data is read in advance and cached in the data cache area.

[0045] The firmware's data processing module executes the prefetch command, reads data of a specified address and length from the NAND flash memory, and stores the read data in the data buffer. This data buffer can be a shared RAM buffer (such as the eMMC's internal SRAM) with the host read / write commands, eliminating the need for a separate prefetch cache.

[0046] In step S130, in response to the current read command, the requested data start address and data read length are compared with the current pre-read data start address and data read length, and the actual read data is returned based on the comparison result.

[0047] Implementing the embodiments of this application, a predictive read command is constructed based on the previous read command. Its starting address is inherited from the ending address of the previous read command, and the data read length is equal to the data read length of the previous read command, thus achieving precise tracking of sequential read commands. When the host issues a read command, the address and length are compared, and the actual read data is returned based on the matching result.

[0048] Since the prefetch operation is performed in the background during the gap between the completion of the data transfer of the previous read command and the arrival of the next read command, the bus is idle between the two read commands. In other words, the prefetch command is processed when the bus is idle. Therefore, the prefetch operation itself does not occupy the critical path time of the host waiting and does not increase the host waiting latency. Regardless of whether the prefetch hits or the prefetch length matches: when the prefetch hits completely or the length is greater than the actual read, all NAND read time is saved; when the prefetch length is less than the actual read, most of the NAND read time is saved. Although a supplementary read is still required, the amount of supplementary read is usually small, and there is still a significant benefit. At the same time, because it shares a RAM cache rather than a separate prefetch cache, the prefetch operation does not occupy valuable cache resources, and even if the prefetch fails, there is no additional time or cache space cost. Lightweight, zero-cost prefetching is achieved at both the time dimension (prefetching during idle time) and the space dimension (shared cache), thus achieving efficient prefetch acceleration without requiring a separate large-capacity RAM.

[0049] Please refer to Figure 3 In at least one possible implementation, returning the actual data read this time based on the comparison result specifically includes: In step S1301, if the comparison results are the same, the pre-read data is directly returned as the actual read data. In steps S1302 and S1303, if the comparison result is only that the data reading length is different, then the actual reading data is obtained based on the current pre-read data, and the actual reading data is returned.

[0050] By implementing the embodiments of this application, the length deviation between the host read request and the pre-read data can be flexibly handled by distinguishing between the two cases of "complete match" and "different length", avoiding the discarding of the entire pre-read data due to length mismatch and improving the utilization rate of the pre-read data.

[0051] Specifically, in at least one possible implementation, obtaining the current read data based on the current pre-read data specifically includes: In step S1302, if the length of the current pre-read data is greater than the length of the current actual read data, then the current actual read data is selected from the current pre-read data and returned. In step S1303, if the length of the current pre-read data is less than the length of the current actual read data, then the difference between the length of the current actual read data and the length of the current pre-read data is read and combined with the current pre-read data to form the current actual read data and returned.

[0052] By implementing the embodiments of this application, the precise matching between the pre-read data and the actual request data is achieved through interception or supplementary reading, so that the pre-read data can be effectively utilized regardless of whether it is greater or less than the actual request, thereby maximizing the benefits of pre-reading.

[0053] In at least one possible implementation, after selecting and returning the currently read data from the currently pre-read data, the method further includes: Clear the data that was not selected in this pre-read data; or After the data for this pre-read is read and cached in the data cache, the following steps are also included: In step S1304, if the current predictive read command fails, the current read data cached in the data buffer will be cleared.

[0054] By implementing the embodiments of this application, valuable data cache resources are released in a timely manner by clearing invalid or unused pre-read data, thus avoiding cache pollution and improving memory utilization efficiency.

[0055] In at least one possible implementation, the current predictive read-ahead command is determined to be invalid under the following conditions: If, after the pre-read data has been read and cached in the data buffer, the received command is not a read command, then the predictive pre-read command is deemed invalid; or If the read command is not received within the preset time, the predictive read command is deemed invalid; or If the comparison result shows that the starting address of the actual read data is different from the starting address of the pre-read data, then the predictive pre-read command is determined to be invalid.

[0056] By implementing the embodiments of this application and setting various failure conditions (non-read command, timeout, address mismatch), it is ensured that the pre-read resources will not be occupied ineffectively for a long time, thereby improving the responsiveness and resource utilization of the system.

[0057] In at least one possible implementation, after returning the data read in this instance, the method further includes: Construct the next predictive read command. The start address of the read data of the next predictive read command is inherited from the end address of the data of the current read command, and it has the same data read length as the current actual read data.

[0058] After each successful return of the read data, the firmware updates the parameters for the next read command: the starting address inherits from the ending address of the current read command, and the length is equal to the length of the read data. Specifically, the currently predicted data read length is defined as N, the actual data read length by the host is defined as M, and the data read length for the next read command is defined as K. 1) N = M, the pre-read data sizes are the same, and set the next pre-read data length K = M; 2) N>M, the pre-read data is greater than the actual data volume, the firmware stops reading new data, and sets the next pre-read data length K = M; 3) N<M, the pre-read data is less than the actual data volume, after the firmware sets N = M, it reads the remaining data volume, and sets the next pre-read data length K = M; Note: For the CMDQ command, the pre-read command parameter is the real CMDQ read command parameter.

[0059] Implementing the embodiments of the present application, by setting the next pre-read length to the current actual read length (K = M), the self-adaptive tracking of the pre-read length is achieved. This feedback-based self-adaptive adjustment mechanism enables the pre-read length K to quickly follow the change of the host's actual read length M and adjust rapidly, avoiding over-pre-reading or under-pre-reading. Through the above mechanism, regardless of the deviation between the current pre-read length and the host request length (under-pre-reading or over-pre-reading), the next pre-read length K will immediately be adjusted to the current actual request length M of the host. This feedback-based self-adaptive adjustment enables the pre-read length to quickly converge to the host's true read step length, effectively avoiding cumulative deviation and maintaining a high hit rate even in scenarios such as file system fragmentation.

[0060] Next, the comparison result processing flow of the embodiments of the present application will be described in detail.

[0061] When the host issues a real read command, the firmware first compares the start address and data length of this read command with the start address and data length of the current pre-read command. According to the comparison results, there are the following situations: If the start address and data length are both the same, the pre-read data is completely hit, and the pre-read data is directly returned as the current actual read data; If the start address is the same but the lengths are different, intercept or read additional data according to the length difference; If the start addresses are different, the pre-read fails, the pre-read data is ignored, and it is processed as a regular read command.

[0062] Regarding the situation where the start address and data length are both the same, that is, the pre-read is completely hit: Suppose the previous read command reads the address 0x1000~0x2000, with a length of 0x1000.

[0063] The firmware constructs a pre-read command with a start address of 0x2000 and a length of 0x1000, and pre-reads this segment of data into the cache.

[0064] Subsequently, the host issues a read command with a start address of 0x2000 and a length of 0x1000.

[0065] After receiving the read command, the firmware compares it with the pre-read data. If the starting address and length match perfectly, it directly returns the pre-read data in the cache to the host with extremely low latency.

[0066] When the prefetch data perfectly matches the start address and length of the host read command, the prefetch data hit is 100%. Since the prefetch operation is completed when the bus is idle, the host read command can directly retrieve data from the RAM cache and return after arrival, without accessing the NAND flash memory. Compared with regular read commands without prefetching, the read latency is reduced from NAND read time (typically 50~100μs) to cache access time (<1μs), and the sequential read bandwidth can be improved by 1 to 2 orders of magnitude. At the same time, since no invalid prefetch data is generated, bus bandwidth and cache resources are fully utilized, resulting in minimal power consumption.

[0067] For cases where the starting address is the same but the length is different, the length of the pre-read data is greater than the actual request length: Assuming the pre-read data length is 0x1000 (address 0x2000~0x3000), the host requests a read command; After several full-hit prefetches (the data length of sequential read commands is usually fixed), the read command issued by the host changes, with its starting address at 0x2000 and its length becoming 0x800.

[0068] After receiving the read command, the firmware compares it with the pre-read data. Finding that the starting address is the same but the requested length is less than the pre-read length, it extracts the first 0x800 bytes (addresses 0x2000~0x2800) from the pre-read data and returns it to the host. Simultaneously, it clears the unused remaining portion (0x2800~0x3000) of the pre-read data, releasing cached resources. In this scenario, the length of the next pre-read command will be updated to the actual request length of 0x800, achieving adaptive adjustment.

[0069] When the host read command length shortens (e.g., from 0x1000 to 0x800), partial hits can still be achieved by truncating the beginning of the pre-read data and returning it to the host. Unused pre-read data can be cleared promptly, releasing cache resources. This also saves the time required to read all 0x800 data from the NAND (because the actual required 0x800 data is already included in the pre-read data). Although a small amount of redundant data is pre-read, this redundant data is read when the bus is idle, and does not occupy the critical path time waiting for the host, nor does it cause additional critical path delays. Compared to traditional independent caching schemes where pre-read data may occupy the cache for a long time, leading to resource waste, this application embodiment minimizes resource waste through a "use and clear" mechanism.

[0070] For cases where the starting address is the same but the length is different, and the pre-read data length is less than the actual request length: Assuming the pre-read data length is 0x1000 (address 0x2000~0x3000), the host requests a read command; After several full-hit prefetches, the read command issued by the host became starting at address 0x2000 and length 0x1800.

[0071] After receiving the read command, the firmware compares it with the pre-read data. Finding that the address is the same but the requested length is greater than the pre-read length, it reads the remaining 0x800 bytes (addresses 0x3000~0x3800) and returns both the pre-read data (0x2000~0x3000) and the supplemented data (0x3000~0x3800) to the host. In this scenario, the length of the next pre-read command will be updated to the actual request length of 0x1800, achieving adaptive adjustment.

[0072] When the length of the host read command increases (e.g., from 0x1000 to 0x1800), the remaining part (0x800) is read in advance, achieving "partial hit + dynamic read in advance". Although read in advance is required, it still saves the NAND read time of the pre-read part (0x1000). Since only the read in advance part (0x800) needs to be read, there is still a significant benefit.

[0073] Meanwhile, this application embodiment features an adaptive length adjustment mechanism: after the current processing is completed, the length of the next pre-read command will be automatically updated to the actual request length (0x1800), thereby quickly tracking changes in the host read length, and subsequent commands can then return to a fully hit state. This feedback adjustment avoids the problem of repeated under-reading or over-reading due to length mismatch in traditional pre-reading algorithms, resulting in a high long-term average hit rate.

[0074] For other read-ahead failure scenarios: If the starting address of the read command issued by the host is different from the starting address of the pre-read data (e.g., random read), or if the host does not issue a read command (e.g., it becomes a write command), or if a matching read command is not received within a timeout, the firmware determines that the predictive pre-read command has failed. In this case, the pre-read data in the cache can be cleared to release resources.

[0075] When a read-ahead command fails due to address mismatch, receiving a non-read command, or a read command timeout, simply clear the read-ahead data in the cache and release the resources. Since the read-ahead operation is performed entirely when the bus is idle, its execution does not consume the critical path time of the host read command. Therefore, although the read-ahead operation fails, it will not increase any additional host waiting latency.

[0076] Traditional read-ahead failures can lead to resource waste because the independent cache is occupied by invalid data for a long time, and the invalid read-ahead itself occupies bus bandwidth that should be used for other commands. However, the "execute when idle, release upon failure" method of this application's embodiment achieves read-ahead failure with near-zero cost, without affecting the normal processing latency of host commands or increasing additional power consumption. This is especially important for embedded scenarios with frequent random access or mixed commands.

[0077] In at least one possible implementation, to prevent prefetched data from occupying valuable RAM cache for an extended period, the firmware incorporates a timeout mechanism. If no matching read command is received within a preset time (e.g., 100ms) after the prefetch command is constructed, the prefetch command is automatically invalidated, and the cached data is cleared. Similarly, if the next command received is not a read command (e.g., a write command, erase command, etc.), the prefetch command is also immediately invalidated.

[0078] Please refer to Figure 4 In at least one possible implementation, to distinguish between read-ahead commands and actual commands, the method further includes: In step S1500, when constructing the predictive read-ahead command, the command state is set to read-ahead mode. In read-ahead mode, only data reading and caching are performed, and data transmission is not performed. Please continue to refer to this. Figure 3 In step S1501, in response to the read command, the command state is set to transmission mode, in which data reading and data transmission are performed.

[0079] By implementing the embodiments of this application, the distinction between dual-state modes (read-ahead mode / transfer mode) allows the same command object to play different roles at different stages, eliminating the need for additional descriptor tables or state machines and reducing firmware complexity. In read-ahead mode, only data reading and caching are performed, without transmitting any data to the host. In transfer mode, cached data is sent to the host. By setting different state parameters, precise distinction and processing between read-ahead data and actual read data can be achieved.

[0080] In at least one possible implementation, setting the command state to read-ahead mode specifically includes: setting the command receive identifier (CMDIN) of the predictive read-ahead command to a first value; Setting the command status to transmission mode specifically includes setting the command receive identifier (CMDIN) of the read command to a second value.

[0081] In implementing the embodiments of this application, the firmware adds a Command Receiver Identifier (CMDIN) status flag to each read command. When constructing a read-ahead command, the Command Receiver Identifier (CMDIN) is set to a first value, such as "0" (read-ahead mode), and the data processing module only performs data reading and buffering without initiating data transmission to the host. When the firmware detects that a read command issued by the host matches the read-ahead command address, it sets the Command Receiver Identifier (CMDIN) of that read command to a second value, such as "1" (transfer mode), at which point the data processing module transmits the buffered data to the host. Through this simple dual-state identification, state differentiation can be achieved with a single binary bit, eliminating the need for complex descriptor tables and state machines, reducing firmware complexity, and resulting in extremely low hardware overhead, making it very suitable for resource-constrained environments in embedded devices.

[0082] In at least one possible implementation, the data cache is a RAM cache shared with read commands.

[0083] Implementing the embodiments of this application, since prefetching is only for a single read command, the length of the prefetched data is basically the same as the length of the cached data for a single read command. Therefore, the prefetched data and the host read / write commands can share the same RAM buffer, eliminating the need for a separate prefetch cache and further reducing memory requirements. When the bus is idle, the previously unused buffer is used for prefetched data storage, achieving near-zero overhead in both time and space dimensions.

[0084] In at least one possible implementation, to avoid meaninglessly constructing pre-read commands in random read scenarios, the firmware performs a sequential read mode determination before executing the pre-read. Specifically, before constructing the current pre-read command, the following steps are also included: In step S100, it is determined whether the previous read command constitutes a read command with one or more previous read commands in a contiguous address. If so, the construction of the current predictive read command is triggered.

[0085] In implementing the embodiments of this application, the firmware records the starting addresses of the most recent read commands. If these addresses increment consecutively (i.e., the end address of the previous command equals the starting address of the next command), it is determined to be a sequential read mode, triggering the construction of a pre-read command. Otherwise, pre-reading is not performed. By triggering pre-reading only when a sequential read mode is detected, meaningless pre-reading operations are avoided in random read scenarios, reducing unnecessary background reads and cache usage, and lowering power consumption.

[0086] In at least one possible implementation, to achieve compatibility with notification-based read-ahead commands, the method further includes: In step S160, in response to receiving a notification-based read-ahead command, the predictive read-ahead command is not constructed, and the notification-based read-ahead command is executed directly.

[0087] In implementing the embodiments of this application, when the storage device receives a notification-based read-ahead command (such as a CMDQ command in the eMMC protocol), the firmware skips the predictive read-ahead construction step of this application and directly executes the command according to the protocol. That is, the notification-based read-ahead command itself already contains complete read request information, and the device does not need to make additional predictions; it only needs to read and transmit data according to the command. This design enables the embodiments of this application to be seamlessly compatible with existing CMDQ-supporting devices, allowing this method to be seamlessly integrated into a hybrid command environment that supports both CMDQ and Non-CMDQ. The device can automatically select the optimal read-ahead strategy based on the command type.

[0088] Obviously, compared with the prior art, the pre-reading method provided in this application has at least the following beneficial effects: Compared to the data prefetching technology of a single CMDQ read command, the embodiments of this application construct a predictive prefetching command and perform prefetching processing during the bus idle gap between two read commands, which greatly reduces the firmware implementation difficulty and the consumption of hardware RAM resources. Its prefetching performance basically reaches the CMDQ sequential read performance. The pre-read data length and the host read command length are adaptively tracked to avoid bandwidth waste caused by reading too much or too little data, providing high performance and low latency; The prefetch object is a single read command, and the prefetched data is only used by the next read command. It does not support inheritance by multiple read commands, thus avoiding the potential risk of inconsistencies in prefetched data and significantly shortening the firmware development cycle.

[0089] For embedded low-power storage devices, the lightweight prefetching technology solution of this application embodiment can significantly reduce the amount of cached data to be prefetched, and will not cause a large impact on power consumption regardless of whether the prefetched data is effective. It can be applied to embedded storage devices such as SD Card / UFS, significantly improving their sequential read performance.

[0090] The pre-read method of this application embodiment is described in detail below with specific examples.

[0091] This example uses an eMMC 5.1 storage device that supports both CMDQ and Non-CMDQ command modes. The device has 32KB of internal SRAM for data caching and firmware operation. The host is an Android smartphone with an F2FS file system. In a sequential read scenario, each read command is assumed to be 16KB long, and the pre-read cache is 16KB.

[0092] initialization: After the device is powered on, the firmware initializes the prefetch related data structures: the command receive flag (CMDIN) status bit is cleared, the prefetch buffer pointer is set to null, and the sequential read mode counter is cleared.

[0093] Sequential read pattern detection: The host issues its first read command: address 0x0000, length 16KB. The firmware processes it normally and records the end address 0x4000.

[0094] The host issues a second read command: address 0x4000, length 16KB. The firmware detects consecutive addresses (the previous end address equals the current start address) and increments the sequential read mode counter by 1. When two consecutive address read commands are executed, it is determined to be in sequential read mode, and pre-reading is enabled.

[0095] Construct read-ahead command: After the second read command is processed, the firmware constructs a pre-read command, which includes the following three parameters: starting address, data length, and command receive identifier (CMDIN) status.

[0096] Start address = 0x8000, data length = 16KB, command receive flag (CMDIN) set to 0 (read-ahead mode).

[0097] 16KB of data (0x8000~0xC000) is pre-read from NAND into the shared RAM cache.

[0098] The host issues the third read command: address 0x8000, length 16KB. A cache hit occurs, and the command is returned directly from the cache with extremely low latency. Simultaneously, the next read-ahead command is constructed: starting address 0xC000, length 16KB. This process continues in this manner.

[0099] Length adaptive: Suppose that the data length requested by a host read command becomes 32KB (for example, the file system adjusts the read window). The previous read command was 16KB long, the prefetch command was 16KB long, and the starting address was 0x10000. The host issues a read command starting at address 0x10000 with a length of 32KB.

[0100] Firmware comparison: Address match, prefetch length 16KB is less than the requested 32KB. Therefore, the prefetched 16KB is returned first, and the remaining 16KB is read and returned. Simultaneously, the next prefetch length is updated to 32KB, starting at address 0x12000. Thereafter, the prefetch length automatically adjusts to 32KB to adapt to the host's new step size.

[0101] Failure handling: When a host prefetch command is deemed invalid—for example, if the host issues a write command (not a read command) after the prefetch command is constructed, or a random read command (data start address mismatch)—the firmware detects the command parameter mismatch, immediately invalidates the prefetch command, invalidates the data, clears the cache, and releases the prefetch RAM buffer. Additionally, the firmware can add a prefetch command timeout mechanism. If the host does not issue commands for an extended period—for example, if no commands are received within 100ms after the prefetch command is constructed—the prefetch command times out, invalidates the prefetched data, and releases the cache.

[0102] Notification-based read-ahead compatibility: When the host issues multiple read commands using the CMDQ command, the firmware recognizes them as notification-based read-ahead commands. Instead of executing the predictive read-ahead process described above, it processes them directly according to the CMDQ protocol, executing each command in the command queue sequentially and returning data.

[0103] The implementation of this example generally includes the following main processes: Sequential read mode determination: If there are multiple consecutive read commands for sector addresses, the device determines that the current host read mode is sequential read, and the firmware records the end address of the latest read command, the value of which is predicted as the start address of the next read command; Construction and processing of predictive read commands: The firmware creates a predictive read command based on the start address and data length of the predicted read command and submits it to the firmware data processing module, which then begins data read-before reading.

[0104] Prefetch command judgment and inheritance: When the firmware detects a command issued by the host, if the host command is a read command and the command start address is consistent with the parameters of the currently constructed predictive prefetch command, the command status is updated to TRUE. Prefetch data transmission: The firmware transmits the cached data to the host. If the cached data is less than the data requested by the host, the firmware continues to read and transmit data to the host until the command ends. Update the next pre-read command: For Non-CMDQ commands, the firmware dynamically sets the start address and length of the next pre-read data based on the end address and length of the currently processed read command; for CMDQ commands, the firmware updates the pre-read information based on the actual start address and length of the next CMDQ command.

[0105] The implementation of the above main processes has yielded the following beneficial results: Extremely low resource consumption: The prefetched data shares the same RAM cache as the host data, with no independent prefetch cache; index management only needs to record the starting address and length (a few bytes) of the prefetch command. Total memory overhead is less than 1KB. It also includes setting timeout and address mismatch conditions to effectively manage the lifecycle of prefetch resources.

[0106] Sequential read performance is significantly improved: In sequential read scenarios, the pre-read hit rate is close to 100%, reducing read latency from NAND read time (about 50μs) to cache hit time (<1μs), and increasing bandwidth by about 50 times.

[0107] Strong adaptability: The read-ahead length can quickly follow changes in the host read length, maintaining a high hit rate even in file system fragmentation scenarios, thus avoiding bandwidth waste caused by excessive read-ahead.

[0108] Good compatibility: It supports both CMDQ and Non-CMDQ commands, requires no modification to the host driver, and can be deployed directly on existing embedded storage devices such as eMMC.

[0109] Please refer to Figure 5 This application also provides a testing device, including a processor 100 and a memory 200, wherein the memory 200 is coupled to the processor 100 and is used to store computer program code, the computer program code including computer instructions, wherein when the processor 100 reads the computer instructions from the memory 200, the processor 100 performs the steps of the method in any possible implementation of any of the foregoing embodiments.

[0110] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the steps of the method in any of the possible implementations of the foregoing embodiments.

[0111] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0112] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A pre-read method applied to an embedded storage device, characterized in that, The pre-read method includes: After the previous read command is completed, the current predictive read command is constructed. The start address of the data to be read in this predictive read command is inherited from the end address of the data in the previous read command, and has the same data read length as the previous read command. According to the predictive prefetch command, the prefetch data is read in advance and cached in the data cache area; In response to this read command, compare the requested data start address and data read length with the start address and data read length of the current pre-read data, and return the actual data read in this operation based on the comparison result.

2. The pre-reading method according to claim 1, characterized in that, The specific details of returning the actual data read in this instance based on the comparison results include: If the comparison results are the same, the data read in this pre-reading will be returned as the data read in this actual reading. If the comparison result is only that the data read length is different, then the actual read data is obtained based on the pre-read data and the actual read data is returned.

3. The pre-reading method according to claim 2, characterized in that, The specific steps of obtaining the actual read data based on the pre-read data include: If the length of the pre-read data is greater than the length of the actual read data, then select the actual read data from the pre-read data and return it. If the length of the pre-read data is less than the length of the actual data read, then the difference between the length of the actual data read and the length of the pre-read data is read and combined with the pre-read data to form the actual data read and returned.

4. The pre-reading method according to claim 3, characterized in that, After selecting and returning the actual data from the pre-read data, the process further includes: Clear the data that was not selected in this pre-read data; or After the data for this pre-read is read and cached in the data cache, the following steps are also included: If the predictive read command fails, the read data cached in the data buffer will be cleared.

5. The pre-reading method according to claim 4, characterized in that, The predictive read-ahead command is deemed invalid under the following conditions: If, after the data has been pre-read and cached in the data cache, the received command is not a read command, then the predictive pre-read command is deemed invalid. or If the read command is not received within the preset time, the predictive read command is deemed invalid; or If the comparison result shows that the starting address of the actual read data is different from the starting address of the pre-read data, then the predictive pre-read command is determined to be invalid.

6. The pre-reading method according to any one of claims 1-5, characterized in that, Before constructing this pre-read command, the following is also included: Determine whether the previous read command constitutes a read command with one or more preceding read commands in a contiguous address sequence. If so, trigger the construction of the current predictive read command.

7. The pre-reading method according to claim 6, characterized in that, After returning the data read in this instance, the following is also included: Construct the next predictive read command. The start address of the read data of the next predictive read command is inherited from the end address of the data of the current read command, and it has the same data read length as the current actual read data.

8. The pre-reading method according to any one of claims 1-5, characterized in that, The method further includes: When constructing the predictive read-ahead command, the command state is set to read-ahead mode. In read-ahead mode, only data reading and caching are performed, and data transmission is not performed. In response to the read command, the command state is set to transfer mode, in which data reading and data transfer operations are performed.

9. The pre-reading method according to claim 8, characterized in that, Setting the command status to read-ahead mode specifically includes: setting the command receiving flag of the predictive read-ahead command to a first value; Setting the command status to transmission mode specifically includes setting the command receiving flag of the read command to a second value.

10. The pre-reading method according to any one of claims 1-5, characterized in that, The data cache area is a RAM cache area shared with read commands.

11. The pre-reading method according to any one of claims 1-5, characterized in that, The method further includes: In response to receiving a notification-based read-ahead command, the predictive read-ahead command is not constructed, and the notification-based read-ahead command is executed directly.

12. A storage device, characterized in that, It includes a processor and a memory coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, which, when the processor reads from the memory, cause the processor to perform the steps in the prefetch method as described in any one of claims 1-11.

13. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the steps of the pre-read method as described in any one of claims 1-11.

Images