Memory processing method and device and computer storage medium

Abstract

The invention provides a memory processing method and device and a computer storage medium. The memory processing method comprises the steps of obtaining a read-write request; determining whether target data accessed by the read-write request is hot data or not; if yes, a hot data memory cache pool is used for completing the read-write request, and the hot data memory cache pool is located in a block device driving layer. By means of the mode, read access is completely completed in the memory cache pool of the driving layer, and a fast path which does not need to access physical storage equipment is formed. According to the path, the physical I / O operation is thoroughly eliminated, and the performance bottleneck caused by read delay and track seeking time in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a memory processing method, apparatus, and computer storage medium. Background Technology

[0002] In modern storage systems, storage devices (such as SSDs, eMMC, and UFS) handle a large number of data read and write tasks. As business demands for high-performance, low-latency access continue to grow, the traditional "write to device, then read" data path faces significant performance bottlenecks. This is especially true for "hot data"—data frequently accessed within a short period—where each I / O operation is performed through the storage device, leading to increased latency and accelerated device wear (such as accelerated NAND Flash lifespan). Summary of the Invention

[0003] To address the aforementioned technical problems, this application proposes a memory processing method, a memory processing device, and a computer storage medium.

[0004] To address the aforementioned technical problems, this application proposes a memory processing method, which includes: acquiring a read / write request; determining whether the target data accessed by the read / write request is hot data; if so, using a hot data memory cache pool to complete the read / write request, wherein the hot data memory cache pool is located in the block device driver layer.

[0005] Wherein, when the read / write request is a read request, the process of using a hot zone memory cache pool to complete the read / write request includes: locating the hot data in the buffer of the hot data memory cache pool; and directly reading data from the buffer to complete the read request.

[0006] Wherein, when the read / write request is a write request, the process of using a hot zone memory cache pool to complete the read / write request includes: locating the buffer in the hot data memory cache pool where the hot data is located; requesting a new cache page from the hot data memory cache pool; applying the write data to the corresponding position of the new cache page; updating the buffer pointer of the hot data to point to the new cache page; releasing the old cache page that the hot data originally pointed to back to the hot zone memory cache pool; completing the write request directly in the hot data memory cache pool; and returning a success status to the upper layer.

[0007] The step of determining whether the target data accessed by the read / write request is hot data includes: parsing the read / write request and extracting the feature information of the read / write request, the feature information including the target logical block address, request size, operation type and / or timestamp; querying the hot data management list to determine whether the target data accessed by the read / write request exists in the hot data management list; if yes, determining that the target data is hot data; if no, determining whether the target data accessed by the read / write request is hot data based on the feature information.

[0008] The step of determining whether the target data accessed by the read / write request is hot data based on the feature information includes: obtaining a sliding time window maintained by the target logical block address, wherein the sliding time window has a predefined window length; using the timestamp to count the number of accesses received within the sliding time window and calculating the average access frequency; comparing the average access frequency with a preset frequency threshold, and identifying the data block corresponding to the logical block address that meets the condition as hot data.

[0009] The memory processing method further includes: determining whether the hot data exists in the hot data management linked list; if so, updating the last access timestamp of the hot data node and incrementing its access count; if not, requesting a contiguous memory space matching the request size from a pre-allocated hot zone memory cache pool; creating a new hot data node and inserting the node into the hot data linked list.

[0010] The memory processing method further includes: triggering a periodic scanning task at a preset time interval to scan the hot data management list; decrementing the access count of the scanned hot data node by a decay factor; comparing the decayed access count with a preset cold data threshold; and if the access count is lower than the cold data threshold, marking the node as cold data and removing it from the hot data management list as a node to be eliminated.

[0011] The memory processing method further includes: saving the information of the currently identified hot data to a non-volatile storage medium; wherein the hot data information includes at least the logical block address of the hot data; reading the hot data information from the non-volatile storage medium when the system starts up again; and pre-establishing corresponding hot data nodes in the hot zone memory cache pool based on the read information to provide hot data caching services immediately when the system starts up.

[0012] To address the aforementioned technical problems, this application proposes a memory processing device, comprising a read / write request processing module, a hot data determination module, and a read / write driver module; the read / write request processing module is used to acquire read / write requests; the hot data determination module is used to determine whether the target data accessed by the read / write request is hot data; the read / write driver module is used to complete the read / write request using a hot data memory cache pool, wherein the hot data memory cache pool is located in the block device driver layer.

[0013] To address the aforementioned technical problems, this application proposes a memory processing apparatus / computer storage medium, the memory processing apparatus comprising a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the memory processing method as described above; and / or, The computer storage medium is used to store program data, which, when executed by the computer, is used to implement the memory processing method described above.

[0014] Compared with existing technologies, the beneficial effects of this application are: the memory processing device obtains a read / write request; determines whether the target data accessed by the read / write request is hot data; if so, it uses a hot data memory cache pool to complete the read / write request, wherein the hot data memory cache pool is located in the block device driver layer. Through this method, read access will be completed entirely in the driver layer's memory cache pool, forming a fast path that does not require access to the physical storage device. This path completely eliminates physical I / O operations, solving the performance bottlenecks caused by read latency and seek time in existing technologies. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the 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. Wherein: Figure 1 This is a flowchart illustrating an embodiment of the memory processing method provided in this application; Figure 2 This is a schematic diagram of the overall process of the memory processing method provided in this application; Figure 3 This is the memory processing method provided in this application. Figure 1 A flowchart illustrating the sub-steps of step S12 in the diagram; Figure 4 This is a flowchart illustrating the second embodiment of the memory processing method provided in this application; Figure 5This is a flowchart illustrating the third embodiment of the memory processing method provided in this application; Figure 6 This is a schematic diagram of the data recovery process provided in this application; Figure 7 This is a schematic diagram of the structure of an embodiment of the memory processing device provided in this application; Figure 8 This is a schematic diagram of another embodiment of the memory processing device provided in this application; Figure 9 This is a schematic diagram of the structure of an embodiment of the computer storage medium provided in this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0017] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] To address the aforementioned technical problems, this application proposes a memory processing method. Please refer to [link / reference needed] for details. Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating an embodiment of the memory processing method provided in this application. Figure 2 This is a schematic diagram of the overall process of the memory processing method provided in this application.

[0019] like Figure 1 As shown, the specific steps are as follows: Step S11: Obtain read / write requests.

[0020] In this embodiment of the application, an operating system driver layer is set up to intercept and process all incoming read / write storage I / O requests.

[0021] At the operating system block device driver layer, real-time interception and feature analysis of raw I / O requests are implemented, independent of and in parallel with any upper-layer file system or application layer caching mechanism.

[0022] Step S12: Determine whether the target data accessed by the read / write request is hot data.

[0023] Specifically, the memory processing device determines whether the target data accessed by the read / write request is hot data by maintaining a hot data management list. When a corresponding data node exists in the hot data management list, the target data accessed is directly determined to be hot data. When a corresponding data node does not exist in the hot data management list, the device further judges based on the characteristic information of the read / write request. If the judgment result is hot data, the maintained hot data management list is further modified; otherwise, the result is determined to be cold data.

[0024] This application proposes specific embodiments for determining thermal data, and includes a thermal data determination module. For details, please refer to [link to specific embodiments]. Figure 3 , Figure 3 This is the memory processing method provided in this application. Figure 1 A flowchart illustrating the sub-steps of step S12 in the diagram.

[0025] like Figure 3 As shown, the specific steps are as follows: Step S121: Parse the read / write request and extract the feature information of the read / write request, the feature information including the target logical block address, request size, operation type and / or timestamp.

[0026] Step S122: Query the hot data management chain to determine whether the target data accessed by the read / write request exists in the hot data management chain.

[0027] If yes, proceed to step S123; otherwise, proceed to step S124.

[0028] Step S123: Determine that the target data is hot data.

[0029] If the target data exists in the hot data management chain, it is directly identified as hot data.

[0030] Step S124: Determine whether the target data accessed by the read / write request is hot data based on the feature information.

[0031] In one embodiment of this application, the memory processing device obtains a sliding time window maintained by the target logical block address, the sliding time window having a predefined window length; uses the timestamp to count the number of accesses received within the sliding time window and calculates the average access frequency; compares the average access frequency with a preset frequency threshold, and identifies the data block corresponding to the logical block address that meets the condition as hot data.

[0032] Specifically, the memory processing device uses a sliding time window algorithm to count the number of times each LBA (Logical Block Address) is accessed in real time within a recent period, as an important indicator for judging hot data.

[0033] The sliding time window algorithm is a real-time statistical technique used to accurately track the frequency of data access within a specific time period.

[0034] A sliding window algorithm is used to divide the time window into multiple buckets, each recording the number of accesses within a certain period. A sliding window structure is created for each monitored LBA. All buckets are initialized to 0, and the window start time is set to the current time. When an LBA is accessed (i.e., an I / O request arrives), the timestamp of this I / O request, now_ts, is obtained. The sliding window structure corresponding to that LBA is retrieved, and it is determined whether the current time exceeds the time range of the current bucket. If so, the window is moved, old buckets exceeding the window time are cleared to zero, and a new bucket is created, adding the access count to the current bucket.

[0035] The default time window length T_window is 500ms. The window length can be dynamically adjusted according to the system load. For example, the window can be shortened under high load to improve sensitivity, and extended under low load to smooth statistical fluctuations.

[0036] The real-time access frequency F is calculated using the following formula: F = C_total / T_window T_window is a 500ms window.

[0037] Where F is the average access frequency of the LBA in the most recent 500ms time window (unit: times / second).

[0038] Define a threshold F_threshold of 100 times / second. If F >= F_threshold, then the LBA range is considered hot data.

[0039] In other embodiments of this application, the frequency features of sliding time window statistics can be integrated into the LSTM prediction model, which can not only improve the accuracy of hot data identification, but also enable the prediction of future access trends.

[0040] In other embodiments of this application, I / O access characteristics at different time periods can also be identified through time distribution features, such as regular access, data requests with fixed periods, such as heartbeat packets and timed synchronization. Random access can also be performed, such as Poisson distribution characteristics, such as user interaction operations, burst access, and continuous access followed by long periods of silence in a short period of time, such as batch data import.

[0041] Furthermore, in one embodiment of this application, the process of maintaining a hot data management linked list is also included. The memory management device determines whether the hot data exists in the hot data management linked list. If so, the last access timestamp of the hot data node is updated and its access count is incremented. If not, a contiguous memory space matching the requested size is requested from a pre-allocated hot zone memory cache pool. A new hot data node is created and inserted into the hot data linked list.

[0042] Specifically, if the node corresponding to the hot data is found in the hot data management chain, the last_access_ts of that node is updated, and access_count is incremented.

[0043] If newly identified data is hot data (i.e., it is identified as hot data but not yet in the hot data management chain), a new hot data node (hot_data_node) is created by requesting contiguous memory of size len from the hot zone memory cache pool. This node is populated with offset, len, type (initialized to the current request type), last_access_ts=now_ts, access_count=1, and buffer (pointing to the requested memory). The data block [offset, offset+len] from the underlying storage device is synchronously read into the newly requested buffer to ensure the memory cache data is valid.

[0044] Step S13: The hot data memory cache pool is then used to complete the read and write requests.

[0045] In this embodiment, the hot data memory cache pool is located in the block device driver layer.

[0046] When the hot data determination module identifies the data accessed in the current I / O request as hot data, the system will no longer follow the traditional I / O path to send the request to the physical storage device. Instead, it will trigger the hot data access control logic and use the hot data memory cache pool to complete the read / write request.

[0047] The hot data memory cache pool provides efficient and stable memory storage for hot data. During initialization, a large contiguous block of physical memory is pre-allocated as a memory pool using a big-page mechanism to avoid dynamic allocation latency. The entire pre-allocated memory pool is then divided into several large page blocks (e.g., 2MB blocks), and these blocks are added to the free_list. When a new range of hot data is detected, a memory request is initiated, and the free_list is traversed to find the free block that satisfies the request size while having the smallest remaining space.

[0048] If the pre-allocated memory pool is insufficient, it can be dynamically expanded, or some frequently accessed data can be compressed to reduce the memory pool's usage.

[0049] In this embodiment, the physical memory page where the hot zone memory cache pool is located is mapped to the kernel's virtual address space when the system starts up, and the kernel can access it directly.

[0050] In one embodiment of this application, when the operation type is a read operation, the hot data is located in the buffer in the hot data memory cache pool; data is directly read from the buffer to complete the read request.

[0051] Specifically, the memory processing device locates the corresponding hot data node (hot_data_node) in the hot data linked list based on the requested target logical block address (LBA), and calculates the specific offset of the data within the buffer in the hot data memory cache pool to determine the cache page it resides in. Kernel functions such as `kmap_atomic()` are called to temporarily map the cache page to the kernel address space, obtaining a directly operable kernel virtual address. Mechanisms such as `copy_to_user()` are used to copy the data from the mapped kernel address to the user-requested buffer. `kunmap_atomic()` is then called to unmap the temporary address. After these steps are successful, the read I / O request is completed directly within the block device driver layer, and the data is returned to the upper layer. Thus, the read request is completely processed without initiating any access commands to the physical storage device.

[0052] In one embodiment of this application, when the operation type is a write operation: the hot data is located in the buffer of the hot data memory cache pool; a new cache page is requested from the hot data memory cache pool; the write data is applied to the corresponding position of the new cache page; the buffer pointer of the hot data is updated to point to the new cache page; the old cache page originally pointed to by the hot data is released back to the hot data memory cache pool; the write operation is completed directly in the hot data memory cache pool, and a success status is returned to the upper layer.

[0053] Specifically, the target hot data node and its current buffer are located. Instead of directly modifying the original buffer, a new cache page is requested from the hot data memory cache pool. The data to be written by the user is applied to the corresponding position of the new cache page. Through an atomic operation, the buffer pointer of the hot data node is updated to point to the new cache page. The old cache page it was pointing to is released back to the hot data memory cache pool for subsequent allocation. A write success status is immediately returned to the upper layer at the block device driver layer. This return of success status occurs before the data is written to the physical storage device.

[0054] By utilizing a hot data memory cache pool to complete the read and write requests, the hot data reading path is transformed from high-latency physical device access to nanosecond-level memory access, achieving an order-of-magnitude speed improvement.

[0055] By using copy-on-write and asynchronous write-back mechanisms, the response latency of write requests is decoupled from the write speed of physical storage devices, achieving fast response and I / O merging, which improves user experience and reduces device wear and tear.

[0056] By handling a large number of frequent I / O requests in memory, the workload and pressure on the underlying physical storage devices are significantly reduced. The entire acceleration process is unnoticed by upper-layer applications and the file system, achieving non-intrusive performance optimization.

[0057] In summary, this embodiment constructs a high-speed I / O channel parallel to the physical device through accurate thermal data judgment and efficient memory pool operation, thereby achieving synergistic optimization of storage system performance and reliability.

[0058] Furthermore, this application also proposes an embodiment for data cooling, managing the lifecycle of hot data, reclaiming cold data resources, and achieving efficient reclamation of memory resources. Please refer to [link / reference] for details. Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the memory processing method provided in this application.

[0059] like Figure 4 As shown, the specific steps are as follows: Step S21: Trigger periodic scanning tasks at preset time intervals to scan the thermal data management chain.

[0060] Specifically, the memory processing device starts a kernel thread or work queue to scan the hot data management list once at preset time intervals.

[0061] Step S22: Decrement the access count of the scanned hot data nodes by a decay factor.

[0062] Specifically, the memory processing device decrements the access_count of each hot data node in the linked list by 1.

[0063] Step S23: Compare the decayed access count with the preset cold data threshold.

[0064] Specifically, the memory processing device checks access_count. If access_count is less than a preset cold data threshold, the node is marked as cold data.

[0065] Step S24: If the access count is lower than the cold data threshold, the node is marked as cold data and removed from the hot data management list as a node to be eliminated.

[0066] Specifically, the memory processing unit creates a writeback task. It ensures that the memory page data corresponding to the cold data node is valid. The data is synchronously written back from the memory cache to the original location (offset, en) of the underlying storage device. Upon successful writeback, the memory pages occupied by the node are released back to the hot memory cache pool, and the node is removed from the hot data list.

[0067] In this embodiment of the application, for Write type hot data in the hot data list, the hot area memory cache pool data needs to be written back to the original location of the underlying storage device when the power is off.

[0068] Furthermore, in this embodiment, the memory processing device can perform batch sequential writes, collecting multiple cold data blocks to be written back, reassembling them into consecutive large I / O requests in LBA order, and then writing them to the SSD. This significantly reduces garbage collection (GC) overhead and write amplification within the SSD.

[0069] In one embodiment of this application, batch write-backs are performed during system idle periods or periods of low I / O load to avoid increasing the burden of write-backs during periods of high load.

[0070] When the usage rate of the hot zone memory cache pool exceeds the preset safety threshold, a forced reclamation process is immediately initiated to quickly scan and evict the coldest data to free up memory, without waiting for the next periodic scan.

[0071] Once the data cooling and write-back mechanism confirms that the cold data has been written back and is no longer needed for caching, it initiates a release request and adds the released memory block to the free_list.

[0072] like Figures 5-6 As shown, Figure 5 This is a flowchart illustrating the third embodiment of the memory processing method provided in this application. Figure 6 This is a schematic diagram of the data recovery process provided in this application.

[0073] like Figure 5 As shown, the specific steps are as follows: Step S31: Save the information of the currently identified thermal data to a non-volatile storage medium.

[0074] During system operation, the thermal data and its metadata dynamically identified by the driver layer are temporarily stored in a thermal data linked list in memory.

[0075] To prevent the loss of these valuable operational experiences due to system shutdown or restart, this step will persistently save the core information of the current hot data list to a non-volatile storage medium, such as a specific file on a hard drive or a block of non-volatile memory, at a specific time.

[0076] The thermal data information includes at least the logical block address of the thermal data.

[0077] In this embodiment of the application, when the system is normally shut down or periodically, the valid metadata in the current hot data list is saved to a region of non-volatile storage.

[0078] The valid metadata in the hot data list includes offset, the starting logical block address of the hot data on the storage device, len the length of the physical blocks in the continuous cache, type representing read or write, access_count the access count, the storage format file header used for initial heat assessment during recovery, magic number + version number + number of nodes + checksum (such as CRC32), and the data body, which stores the metadata fields of each hot_data_node continuously.

[0079] Specifically, the memory processing device acquires the lock of the hot data list, traverses the list, collects the specified metadata of all valid hot data nodes (hot_data_node), serializes the collected data according to a predetermined format, writes the serialized data to non-volatile storage, and finally releases the lock.

[0080] Step S32: When the system is started up again, read the thermal data information from the non-volatile storage medium.

[0081] When the system performs its next cold boot, the operating system and driver layer will load sequentially. In this application, the block device driver layer proactively performs a crucial action in the early stages of initialization: it reads a snapshot file of the saved hot data information from the previously stored non-volatile storage medium into memory. The driver layer has already obtained the hot data accumulated in the previous runtime cycle before it even begins processing any application I / O requests.

[0082] During system startup and storage driver initialization, hot data metadata is read from non-volatile storage, the hot data linked list is rebuilt, and pre-filling of the hot zone memory cache pool is triggered. The header of the data file on the non-volatile storage is read, and the magic number, version number, and checksum are verified to confirm valid data. If valid data exists, subsequent metadata records are read based on the number of nodes. A new `hot_data_node` structure is created for each metadata record. The `offset`, `len`, `type`, and `access_count` fields are populated, and pre-fetching is triggered to request a memory buffer of size `len` from the hot zone memory cache pool. During storage device idle periods, asynchronous I / O requests are initiated to asynchronously read data blocks (`offset`, `offset+len`) from the underlying storage device into the newly requested buffer. Historical hot data is loaded into memory before user I / O occurs. Finally, the new node is added to the hot data linked list.

[0083] Step S33: Based on the information read, pre-establish the corresponding hot data node in the hot zone memory cache pool to provide hot data caching service immediately when the system starts.

[0084] Simply reading the information is insufficient; it must be transformed into a usable service. In this step, the driver layer proactively and pre-initializes its caching system based on the hot data information (LBA list) read in step S32. For each recorded LBA, it requests memory space from the hot zone memory cache pool, creates the corresponding hot data node, and reconstructs the hot data linked list.

[0085] When a user program starts and issues its first I / O request, if the data requested is in the previously persisted list of hot data, the system can immediately achieve a cache hit and provide the data directly from memory.

[0086] This allows the system to be in its optimal or near-optimal performance state the moment it starts up, achieving zero warm-up startup, which is crucial for applications such as databases and web servers that need to be put into service quickly.

[0087] This application directly perceives I / O request characteristics through the operating system driver layer, rather than relying on upper-layer cache or file system, to achieve accurate hot data determination, cache it in memory, and bypass the storage device for subsequent accesses, thereby reducing latency and write amplification.

[0088] This application adds a function to save and restore hot data metadata, enabling the system to save its learning results when shutting down and quickly restore this information upon the next startup, while proactively preloading historical hot data into memory. This significantly shortens the warm-up time to reach optimal performance, giving the system optimization effects a memory function and continuity, which is something that upper-layer caching solutions simply cannot achieve, thus solving the core pain point in scenarios with frequent restarts.

[0089] To implement the above memory processing method, this application also proposes another memory processing device, please refer to [link / reference needed]. Figure 7 , Figure 7 This is a schematic diagram of an embodiment of the memory processing device provided in this application.

[0090] The memory processing device 500 in this embodiment includes a read / write request processing module 51, a hot data judgment module 52, and a read / write driver module 53.

[0091] The read / write request processing module 51 is used to obtain read / write requests.

[0092] The hot data determination module 52 is used to determine whether the target data accessed by the read / write request is hot data.

[0093] The read / write driver module 53 is used to complete the read / write request using a hot data memory cache pool, wherein the hot data memory cache pool is located in the block device driver layer.

[0094] To implement the above memory processing method, this application also proposes another memory processing device, please refer to [link / reference needed]. Figure 8 , Figure 8 This is a schematic diagram of another embodiment of the memory processing device provided in this application.

[0095] The memory processing device 400 of this embodiment includes a processor 41, a memory 42, an input / output device 43, and a bus 44.

[0096] The processor 41, memory 42, and input / output device 43 are respectively connected to the bus 44. The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the memory processing method described in the above embodiments.

[0097] In this embodiment, processor 41 can also be referred to as a CPU (Central Processing Unit). Processor 41 may be an integrated circuit chip with signal processing capabilities. Processor 41 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 41 can be any conventional processor.

[0098] This application also provides a computer storage medium; please refer to the following: Figure 9 , Figure 9 This is a schematic diagram of a computer storage medium according to an embodiment of the present application. The computer storage medium 600 stores a computer program 61, which, when executed by a processor, is used to implement the memory processing method of the above embodiment.

[0099] When the embodiments of this application are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A memory processing method, characterized in that, The memory processing method includes: Obtain read / write requests; Determine whether the target data accessed by the read / write request is hot data; If so, the read / write request is completed using a hot data memory cache pool, wherein the hot data memory cache pool is located in the block device driver layer.

2. The memory processing method according to claim 1, characterized in that, When the read / write request is a read request; The process of using a hotspot memory cache pool to complete the read / write requests includes: The hot data is located in the buffer of the hot data memory cache pool; The read request is completed by reading data directly from the buffer.

3. The memory processing method according to claim 1, characterized in that, When the read / write request is a write request; The process of using a hotspot memory cache pool to complete the read / write requests includes: The hot data is located in the buffer of the hot data memory cache pool; Request a new cache page from the hot data memory cache pool; The written data is applied to the corresponding location in the new cache page; Update the buffer pointer of the hot data to point to the new cache page; Release the old cache page that the hot data originally pointed to back into the hot zone memory cache pool; The write request is completed directly in the hot data memory cache pool, and a success status is returned to the upper layer.

4. The memory processing method according to claim 1, characterized in that, Determining whether the target data accessed by the read / write request is hot data includes: The read / write request is parsed, and the feature information of the read / write request is extracted. The feature information includes the target logical block address, request size, operation type, and / or timestamp. Query the hot data management chain list to determine whether the target data accessed by the read / write request exists in the hot data management chain list; If so, the target data is determined to be hot data; If not, determine whether the target data accessed by the read / write request is hot data based on the feature information.

5. The memory processing method according to claim 4, characterized in that, The step of determining whether the target data accessed by the read / write request is hot data based on the feature information includes: Obtain the sliding time window maintained by the target logical block address, wherein the sliding time window has a predefined window length; The timestamp is used to count the number of accesses received within the sliding time window, and the average access frequency is calculated. The average access frequency is compared with a preset frequency threshold, and the data blocks corresponding to the logical block addresses that meet the conditions are identified as hot data.

6. The memory processing method according to claim 5, characterized in that, The memory processing method further includes: Determine whether the heat data exists in the heat data management chain list; If so, update the last access timestamp of the hot data node and increment its access count; If not, request a contiguous memory space matching the requested size from a pre-allocated hot zone memory cache pool; Create a new hot data node and insert it into the hot data linked list.

7. The memory processing method according to claim 1, characterized in that, The memory processing method further includes: Periodic scanning tasks are triggered at preset time intervals to scan the thermal data management chain list; The access count for each scanned hot data node is decremented by a decay factor; The decayed access count is compared with a preset cold data threshold; If the access count is lower than the cold data threshold, the node is marked as cold data and removed from the hot data management list as a node to be eliminated.

8. The memory processing method according to claim 1, characterized in that, The memory processing method further includes: The information of the currently identified thermal data is saved to a non-volatile storage medium; wherein, the thermal data information includes at least the logical block address of the thermal data; The thermal data information is read from the non-volatile storage medium upon the next system startup. Based on the information read, corresponding hot data nodes are pre-established in the hot zone memory cache pool to provide hot data caching services immediately upon system startup.

9. A memory processing device, characterized in that, The memory processing device includes a read / write request processing module, a hot data judgment module, and a read / write driver module; The read / write request processing module is used to obtain read / write requests; The hot data determination module is used to determine whether the target data accessed by the read / write request is hot data; The read / write driver module is used to complete the read / write request using a hot data memory cache pool, wherein the hot data memory cache pool is located in the block device driver layer.

10. A memory processing device / computer storage medium, characterized in that, The memory processing apparatus includes a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the memory processing method as described in any one of claims 1 to 8; and / or, The computer storage medium is used to store program data, which, when executed by the computer, is used to implement the memory processing method as described in any one of claims 1 to 8.

Images