Task identification-based multi-level cache method, system, terminal and storage medium

Abstract

This invention provides a multi-level caching method, system, terminal, and storage medium based on task identifiers, comprising: creating corresponding task identifier information in each request sent by a hardware IP entity to the multi-level caching system; and receiving corresponding cache maintenance strategies provided by the multi-level caching system for each task identifier information. By using the technical solution of this invention, even if there are multiple hardware IP entities with different memory usage methods, they will not affect each other, thus not affecting the performance of the multi-level caching system. This effectively solves the technical problem that the performance of existing multi-level caching systems significantly degrades when encountering multiple hardware IP entities.

Description

Technical Field

[0001] This invention relates to the field of caching technology, and in particular to a multi-level caching method, system, terminal, and storage medium based on task identifiers. Background Technology

[0002] The basic principle of multi-level caching technology is to add one or more levels of storage media between the existing CPU (Central Processing Unit) cache and the system memory in order to save memory costs.

[0003] Currently, multi-level caching technology virtualizes system memory. Specifically, it seems to replace the traditional storage system consisting solely of DDR space with a cache system comprised of a large amount of SSD (Solid State Drive) space and a small amount of DDR (Double Data Rate) space, serving as the system's storage control. This is possible because in a computer system, 1GB of storage space is usually sufficient at any given time. The advantage of this is that it expands system memory while also saving costs.

[0004] In addition, there is a technology that introduces IPM (In-Package Memory) storage media on top of the existing multi-level caching technology. In this way, the system's memory is a two-level cache system composed of IPM storage media, DDR (Double Data Rate Synchronous Dynamic Random Access Memory), and part of SSD (Solid State Drive). This approach inherits the advantages of the original technology in terms of expanding storage space and reducing costs, while also bringing the benefits of improved performance and reduced power consumption.

[0005] However, both of these approaches share a common drawback: they rely excessively on how the system uses memory. If the system contains only one IP master (a hardware IP entity in a SoC (System-on-a-Chip) that can actively initiate memory access requests) or a single type of IP masters, the advantages of caching can be fully utilized. However, if the system contains multiple IP masters, the different memory usage patterns and the ease with which they can interfere with each other can ultimately lead to the performance of the system using caching being lower than that of normal DDR memory. Summary of the Invention

[0006] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a multi-level caching method, system, terminal and storage medium based on task identifiers, which mainly solves the technical problem that the system contains multiple IP masters in the prior art, and the different IP masters have different memory usage methods and are prone to mutual interference, which ultimately leads to the low performance of the application caching system.

[0007] To achieve the above and other related objectives, a first aspect of the present invention provides a multi-level caching method based on task identifiers, comprising: creating corresponding task identifier information in each request sent by a hardware IP entity to a multi-level caching system; and receiving corresponding cache maintenance strategies provided by the multi-level caching system for each of the task identifier information.

[0008] In some embodiments of the first aspect of the present invention, the multi-level caching method further includes starting a resource management thread to manage the cache basic unit resources of all task identifiers.

[0009] In some embodiments of the first aspect of the present invention, the multi-level caching method further includes having the resource management thread manage cache basic unit resources for all task identifiers based on a buddy algorithm.

[0010] In some embodiments of the first aspect of the present invention, the multi-level caching method further includes, after managing the basic unit resources of all task identifiers, creating one or more corresponding performance monitoring threads for the task identifiers to monitor the task identifiers.

[0011] In some embodiments of the first aspect of the present invention, the performance monitoring thread monitors whether the self-cleaning function of the task identifier is frequently triggered in order to adjust the allocation of cache basic units accordingly, wherein frequent triggering is a triggering that exceeds a preset number of times within a preset time period.

[0012] In some embodiments of the first aspect of the present invention, the performance monitoring thread monitors whether the self-cleaning function of the task identifier is frequently triggered, so as to adjust the allocation of cache basic units accordingly. The corresponding process includes: determining whether the self-cleaning function of the task identifier is frequently triggered; if it is not frequently triggered, releasing a certain number of cache basic units; if it is frequently triggered, determining whether there are extra cache basic units; if there are extra cache basic units, allocating them to the task identifier whose self-cleaning function is frequently triggered; if there are no extra cache basic units, increasing the cleanup threshold; after increasing the cleanup threshold, continuing to determine whether the self-cleaning function of the task identifier is frequently triggered; if it is still frequently triggered, increasing the number of dirty bits (Dirty Bit / Bytes, dirty bits set in the cache to maintain data consistency) cache basic unit resources cleaned up in each self-cleaning process.

[0013] In some embodiments of the first aspect of the present invention, the performance monitoring thread monitors the addresses corresponding to cache basic units that are frequently put into and removed from the cache, and uses a Bloom filter to exclude addresses that conform to a preset rule from being added to the cache.

[0014] To achieve the above and other related objectives, a second aspect of the present invention provides a multi-level caching system based on task identifiers, comprising: a task identifier creation module, configured to create corresponding task identifier information in each request sent by a hardware IP entity to the multi-level caching system; and a caching strategy module, configured to receive corresponding caching maintenance strategies provided by the multi-level caching system for each of the task identifier information.

[0015] To achieve the above and other related objectives, a third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-level caching method.

[0016] To achieve the above and other related objectives, a fourth aspect of the present invention provides an electronic terminal, comprising: a processor and a memory; the memory for storing a computer program, and the processor for executing the computer program stored in the memory, so that the terminal executes the multi-level caching method.

[0017] As described above, the multi-level caching method, system, terminal, and storage medium based on task identifiers of the present invention have the following beneficial effects: The technical solution of the present invention includes the identity information of each hardware IP entity in the request sent by each hardware IP entity to the multi-level caching system, so that the multi-level caching system can provide different caching maintenance strategies for different hardware IP entities. Therefore, even if there are multiple hardware IP entities and their memory usage methods are different, they will not affect each other, and thus will not affect the performance of the multi-level caching system. This effectively solves the technical problem that the performance of existing multi-level caching systems will significantly decrease when encountering multiple hardware IP entities. Attached Figure Description

[0018] Figure 1 The diagram shown is a flowchart of a multi-level caching method based on task identifiers according to an embodiment of the present invention.

[0019] Figure 2 The diagram shows the structure of the resource management thread and the performance monitoring thread in one embodiment of the present invention.

[0020] Figure 3 This is a flowchart illustrating the process of a performance monitoring thread monitoring whether the self-cleaning function is frequently triggered, according to an embodiment of the present invention.

[0021] Figure 4 The diagram shown is a structural schematic of a multi-level caching terminal according to an embodiment of the present invention.

[0022] Figure 5 The diagram shown is a structural schematic of a multi-level caching system based on task identifiers according to an embodiment of the present invention. Detailed Implementation

[0023] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0024] It should be noted that in the following description, reference is made to the accompanying drawings, which illustrate several embodiments of the present invention. It should be understood that other embodiments may also be used, and changes in mechanical composition, structure, electrical system, and operation may be made without departing from the spirit and scope of the invention. The following detailed description should not be considered limiting, and the scope of the embodiments of the invention is defined only by the claims of the published patents. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. Spatially related terms, such as “upper,” “lower,” “left,” “right,” “below,” “below,” “lower part,” “above,” “upper part,” etc., may be used herein to illustrate the relationship between one element or feature shown in the figures and another element or feature.

[0025] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," "fixing," and "holding" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0026] Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of the stated feature, operation, element, component, item, kind, and / or group, but do not preclude the presence, occurrence, or addition of one or more other features, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition arise only when combinations of elements, functions, or operations are inherently mutually exclusive in some manner.

[0027] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the invention.

[0028] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:

[0029] <1> Cache Controller: A high-speed cache controller, which is the hardware IP used in multi-level caching technology to manage the cache.

[0030] <2> CL (Cache Line): The basic unit of cache access.

[0031] <3> IPM (In-Package Memory): This is memory integrated within a package, primarily composed of SDRAM, and can be used as a cache medium for system memory. Compared to LPDDR, IPM offers greater bandwidth and lower power consumption, but it needs to be integrated inside the chip.

[0032] <4> LPDDR (Low Power Dual DRAM): Low power dual-core dynamic random access memory, used as a general-purpose storage medium for systems.

[0033] <5> IP master: A hardware IP entity in a SoC system that can proactively initiate requests for system memory access.

[0034] <6> TID (Task Identification): Task identifier; usually, a preset storage bit (reserve bit) in the system bus is defined to store the task identifier TID, so that the cache controller can distinguish which IP master initiated the access to a certain system storage.

[0035] <7> BF (Bloom Filter): A feature integrated into the cache controller that prevents infrequently accessed addresses from being added back to the cache.

[0036] like Figure 1 The diagram illustrates a flowchart of a multi-level caching method based on task identifiers according to an embodiment of the present invention. The multi-level caching method in this embodiment includes the following steps:

[0037] Step S11: Create corresponding task identification information in each hardware IP entity's request to the multi-level caching system.

[0038] In this embodiment, the introduction of Task Identification (TID) means that the request sent by each hardware IP entity to the multi-level caching system includes the identity information of these hardware IP entities. In this way, the multi-level caching system can provide different cache maintenance strategies for different hardware IP entities. Therefore, even if there are multiple hardware IP entities and their memory usage methods are different, they will not affect each other and thus will not affect the performance of the multi-level caching system.

[0039] Suppose that a certain caching system provides the following configurable interface for the software executing the multi-level caching method based on task identifiers in this embodiment:

[0040] 1) Size of Task Identifier (TID): The caching system provides 32*1024 cache basic units (CL). Each Task Identifier (TID) is allocated using 32 cache basic units (CL) (maximum of 1024). Different Task Identifiers (TIDs) can overlap.

[0041] 2) Set a Bloom filter (BF) in the storage space of the task identifier (TID);

[0042] 3) The clean threshold (CT) in the storage space of the task identifier (TID) can be set. If the number of cache basic units (CL) to be cleaned in the storage space of the task identifier (TID) is less than the clean threshold (CT), the self-cleaning function of the task identifier (TID) will be triggered.

[0043] 4) The purge depth (PD) value in the storage space of the task identifier TID can be set; the purge depth refers to the number of dirty CLs cleaned each time the task identifier TID is self-cleaned.

[0044] In some examples, the multi-level caching method further includes starting a resource management thread to manage the cache basic unit resources for all task identifiers.

[0045] Specifically, during initialization, a resource management thread (TID Resource Management thread, abbreviated as TID RM thread) is opened. This thread is responsible for allocating and reclaiming the cache basic unit resources (CL resources) for all task identifiers (TIDs) according to the buddy system algorithm. Users can allocate cache basic unit resources (CL resources) for the currently corresponding task identifier (TID) in this thread during system initialization or at any other time. Those skilled in the art should understand that the TID RM thread mentioned below refers to the resource management thread, and CL resources refer to cache basic unit resources.

[0046] In some examples, the method also includes having the resource management thread manage cached basic unit resources for all task identifiers based on a buddy algorithm.

[0047] Specifically, since all task identifiers (TIDs) are allocated from a common cache basic unit pool (CL pool), and the number must be an integer power of 2, the scenario is almost identical to the memory page allocation scenario in the operating system. Therefore, this embodiment manages cache basic unit resources for all task identifiers based on the buddy algorithm, which can reduce fragmentation and ensure the utilization efficiency of cache basic units (CL).

[0048] The buddy system algorithm is a memory management algorithm in Linux (an operating system) designed to reduce memory waste and avoid memory fragmentation. Memory fragmentation occurs when memory is divided into very small blocks that are free but too small to be used. As the number of allocations and deallocations increases, memory becomes increasingly fragmented, eventually resulting in only fragmented memory. Linux uses the buddy system algorithm to solve this problem. It divides all free pages into 10 block groups, with each block in the group being a power of 2 containing 2 pages. For example, the blocks in group 0 are all 2 pages in size. 0 (1 page), the size of all blocks in the first group is 2. 1 (2 pages)......The size of all blocks in group 9 is 2. 9 (512 pages). Therefore, the block size in each group is the same, and these blocks of the same size form a linked list. Assuming the required block size is 128 pages, the buddy algorithm first searches the linked list of blocks of 128 pages to see if there is such a free block; if there is a free block, it is allocated directly; if not, the algorithm searches for the next larger block.

[0049] In some examples, the method further includes: after managing the basic unit resources of all task identifiers, creating one or more corresponding performance monitoring threads for the task identifiers to monitor the task identifiers.

[0050] For ease of understanding, the structures of the resource management thread and the performance monitoring thread are as follows: Figure 2 As shown: First, a task identifier (User Create TID) is created. Then, a resource management thread is started to allocate cache basic unit resources (CL resources) for the newly created task identifier. After resource allocation, one or more performance monitoring threads (PM Threads) are created to monitor the task identifier.

[0051] In some examples, the performance monitoring thread monitors whether the self-cleaning function of the task identifier is frequently triggered, and adjusts the allocation of cache basic units accordingly. Frequent triggering is defined as triggering more than a preset number of times within a preset time period. For example, more than 10 triggers per second are considered frequent triggering; however, those skilled in the art should understand that the specific numerical range used in the above definition of frequent triggering is only one embodiment of the present invention, and the present invention is not limited to this range of description.

[0052] It should be noted that a cleanup threshold CT is usually set in the task identifier TID space. If the number of cache basic units CL in the task identifier TID space is less than the cleanup threshold CT, the self-cleanup function of the task identifier TID will be triggered.

[0053] Furthermore, the performance monitoring thread monitors whether the self-cleanup function of the task identifier is frequently triggered, so as to adjust the allocation of cache basic units accordingly. The corresponding process includes, for example: Figure 3 As shown, it includes the following steps:

[0054] Step S31: Start the performance monitoring thread.

[0055] Step S32: The performance monitoring thread determines whether the self-cleanup function of the task identifier is frequently triggered.

[0056] It should be noted that a threshold can be set to determine whether the self-cleaning function is frequently triggered. That is, if the frequency of the self-cleaning function being triggered within a certain period exceeds the set threshold, it means that it is frequently triggered; otherwise, it means that it is not frequently triggered.

[0057] Step S33: If not frequently triggered, release a certain number of cache basic units.

[0058] Step S34: If it is triggered frequently, determine whether there are redundant cache basic units.

[0059] Step S35: If there are extra cache basic units, allocate them to the task identifiers that are frequently triggered to clean up.

[0060] In other words, when self-cleaning is frequently triggered, the system first checks if there are any extra cache basic units (CL) that have not yet been used by other task identifiers (TIDs); if there are extra cache basic units (CL), they are allocated to the task identifiers (TIDs) where self-cleaning is frequently triggered.

[0061] Step S36: If there are no extra cache basic units, increase the cleanup threshold.

[0062] Step S37: After raising the cleanup threshold, continue to determine whether the self-cleanup function of the task identifier is frequently triggered; if it is not frequently triggered, return to step S31.

[0063] Step S38: If it is still frequently triggered, increase the number of dirty CLs cleaned up in each self-cleaning process and return to step S31. It should be understood that the number of dirty CLs cleaned up in each self-cleaning process refers to the cleanup depth value in the task identifier TID space.

[0064] In some examples, the performance monitoring thread can be executed continuously in a loop, or at a preset time interval, or interrupted based on a preset interrupt instruction, all of which can be selected and adjusted according to actual needs.

[0065] In some examples, the performance monitoring thread monitors the addresses corresponding to cache basic units that are frequently put into and removed from the cache, and uses a Bloom filter to exclude addresses that conform to a preset pattern from being added to the cache.

[0066] Furthermore, the preset patterns include, but are not limited to, one or more of the following: low access frequency, accessed periodically but infrequently, or accessed periodically but for a long period. These situations are commonly seen in video compression or decompression processes.

[0067] Step S12: Receive the corresponding cache maintenance strategy provided by the multi-level cache system for each task identification information.

[0068] In some examples, the cache maintenance strategy includes, but is not limited to, lazy loading strategy, write-through strategy, and adding time-to-live (TTL) strategy.

[0069] The lazy loading strategy is a caching strategy that loads data into the cache only when needed. The write-through strategy is a strategy that adds or updates data in the cache when data is written to the database. The add-live-time strategy refers to adding a live-time value based on the lazy loading strategy and the write-through strategy, making full use of the advantages of each strategy. For example, the lazy loading strategy allows stale data but will not fail and generate empty nodes, while the write-through strategy ensures that the data is always up-to-date but may fail and generate empty nodes.

[0070] To facilitate understanding, let's take a delayed loading strategy as an example: ElastiCache is an in-memory key-value store located between the current application and the data store (database) it accesses. When an application requests data, it first sends a request to the ElastiCache. If the data is in the ElastiCache and is up-to-date, the ElastiCache returns the data to the application. If the data is not in the ElastiCache or has expired, the application requests the data from the data store. The data store then returns the data to the application. Afterward, the application writes the data received from the storage to the ElastiCache. This allows for faster retrieval of the data on subsequent requests.

[0071] The multi-level caching method based on task identifiers provided in this invention can be implemented on the terminal side or the server side. For the hardware structure of the multi-level caching terminal based on task identifiers, please refer to [link to relevant documentation]. Figure 4 This is a schematic diagram of an optional hardware structure of a multi-level caching terminal 400 based on task identifiers provided in an embodiment of the present invention. The terminal 400 can be a mobile phone, computer device, tablet device, personal digital processing device, factory back-end processing device, etc. The multi-level caching terminal 400 based on task identifiers includes: at least one processor 401, a memory 402, at least one network interface 404, and a user interface 406. The various components in the device are coupled together through a bus system 405. It is understood that the bus system 405 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 405 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 3 The general will label all buses as bus systems.

[0072] The user interface 406 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0073] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0074] In this embodiment of the invention, the memory 402 is used to store various types of data to support the operation of the task-identifier-based multi-level caching terminal 400. Examples of this data include: any executable program that operates on the task-identifier-based multi-level caching terminal 400, such as the operating system 4021 and application program 4022; the operating system 4021 includes various system programs, such as the framework layer, core library layer, driver layer, etc., used to implement various basic services and process hardware-based tasks. The application program 4022 may include various applications, such as a media player, browser, etc., used to implement various application services. The implementation of the task-identifier-based multi-level caching method provided in this embodiment of the invention can be included in the application program 4022.

[0075] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0076] In an exemplary embodiment, the multi-level cache terminal 400 based on task identifiers can be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0077] like Figure 5 The diagram illustrates the structure of a multi-level caching system based on task identifiers according to an embodiment of the present invention. The multi-level caching system 500 includes a task identifier creation module 501 and a caching strategy module 502.

[0078] The task identifier creation module 501 is used to create corresponding task identifier information in each request sent by a hardware IP entity to the multi-level caching system. The caching policy module 502 is used to receive corresponding caching maintenance policies from the multi-level caching system for each task identifier information.

[0079] In some examples, the multi-level caching system 500 also includes a resource management thread module (not shown) for managing the cache basic unit resources for all task identifiers.

[0080] Furthermore, the resource management thread module manages and caches basic unit resources for all task identifiers based on the buddy algorithm.

[0081] In some examples, the multi-level caching system 500 also includes a performance monitoring thread module (not shown) for monitoring task identifiers.

[0082] Furthermore, the performance monitoring thread module monitors whether the self-cleaning function of the task identifier is frequently triggered, and adjusts the allocation of cache basic units accordingly. Frequent triggering is defined as triggering more than a preset number of times within a preset time period. For example, if there are more than 10 triggers per second, it is considered frequent triggering; however, those skilled in the art should understand that the specific numerical range used in the above definition of frequent triggering is only one embodiment of the present invention, but the present invention is not limited to this range of description.

[0083] The performance monitoring thread module monitors whether the self-cleaning function of the task identifier is frequently triggered, and adjusts the allocation of cache basic units accordingly. The corresponding process includes: determining whether the self-cleaning function of the task identifier is frequently triggered; if it is not frequently triggered, releasing a certain number of cache basic units; if it is frequently triggered, determining whether there are extra cache basic units; if there are extra cache basic units, allocating them to the task identifier whose self-cleaning function is frequently triggered; if there are no extra cache basic units, increasing the cleanup threshold; after increasing the cleanup threshold, continuing to determine whether the self-cleaning function of the task identifier is frequently triggered; if it is still frequently triggered, increasing the number of dirty cache basic unit resources cleaned up in each self-cleaning process.

[0084] In some examples, the performance monitoring thread module monitors the addresses corresponding to cache basic units that are frequently put into and cleared from the cache, and uses a Bloom filter to exclude addresses that conform to a preset pattern from being added to the cache; the preset pattern includes any one or more of the following: low access frequency, accessed periodically but infrequently, accessed periodically but for a long period.

[0085] It should be noted that the multi-level caching system based on task identifiers provided in the above embodiments is only illustrated by the division of the above program modules. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the image classification device and image classification method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0086] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the multi-level caching method based on task identifiers.

[0087] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented using computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0088] In the embodiments provided by this invention, the computer-readable and writable storage medium may include read-only memory, random access memory, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, flash memory, USB flash drive, portable hard drive, or any other medium capable of storing desired program code having an instruction or data structure form and accessible by a computer. Additionally, any connection may be appropriately referred to as a computer-readable medium. For example, if the instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. However, it should be understood that computer-readable and writable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are intended for non-transient, tangible storage media. The disks and optical discs used in the application include compact discs (CDs), laser discs, optical discs, digital multifunction discs (DVDs), floppy disks, and Blu-ray discs, where disks typically copy data magnetically, while optical discs use lasers to copy data optically.

[0089] In summary, this invention provides a multi-level caching method, system, terminal, and storage medium based on task identifiers. By including the identity information of each hardware IP entity in the requests sent to the multi-level caching system, the multi-level caching system can provide different caching maintenance strategies for different hardware IP entities. Therefore, even if there are multiple hardware IP entities with different memory usage methods, they will not affect each other, thus not affecting the performance of the multi-level caching system. This effectively solves the technical problem that existing multi-level caching systems experience significant performance degradation when encountering multiple hardware IP entities. Therefore, this invention effectively overcomes the various shortcomings of the prior art and has high industrial application value.

[0090] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for multi-level cache based on task identification, characterized in that, Comprising: creating corresponding task identification information in each request sent by each hardware IP entity to the multi-level cache system; wherein the task identification contains identity information of each hardware IP entity; starting a resource management thread to manage cache basic cell resources of all task identifications; the specific mode comprises: opening the resource management thread at initialization, and enabling the resource management thread to allocate and recycle cache basic cell resources of all task identifications based on a buddy algorithm; after managing cache basic cell resources of all task identifications, creating one or more performance monitoring threads corresponding to the task identifications to monitor the task identifications; wherein the performance monitoring thread monitors whether the self-cleaning function of the task identification is frequently triggered to correspondingly adjust the allocation of cache basic cells; receiving corresponding cache maintenance strategies provided by each task identification information from the multi-level cache system; wherein the performance monitoring thread monitors whether the self-cleaning function of the task identification is frequently triggered to correspondingly adjust the allocation of cache basic cells, and the corresponding process comprises: judging whether the self-cleaning function of the task identification is frequently triggered; specifically, if the number of cache basic cells in the task identification space is less than a set cleaning threshold, the self-cleaning function of the task identification is triggered; if the frequency of triggering the self-cleaning function of the task identification within a certain period exceeds a set threshold, the self-cleaning function of the task identification is frequently triggered; otherwise, the self-cleaning function of the task identification is not frequently triggered; if not frequently triggered, releasing a certain number of cache basic cells; if frequently triggered, judging whether there are surplus cache basic cells; if there are surplus cache basic cells, allocating them to the task identification whose self-cleaning function is frequently triggered; if there are no surplus cache basic cells, raising the cleaning threshold; after raising the cleaning threshold, continuing to judge whether the self-cleaning function of the task identification is frequently triggered; if still frequently triggered, increasing the number of dirty bit cache basic cell resources cleaned up in each self-cleaning process.

2. The method of claim 1, wherein, The performance monitoring thread monitors the addresses of cache basic cells frequently put into and removed from the cache, and uses a Bloom filter to exclude addresses conforming to a preset rule from being added to the cache.

3. A multi-level cache system based on task identification, characterized in that, Comprising: a task identification creation module configured to create corresponding task identification information in each request sent by each hardware IP entity to the multi-level cache system; wherein the task identification contains identity information of each hardware IP entity; a resource management thread module configured to start a resource management thread to manage cache basic cell resources of all task identifications; the specific mode comprises: opening the resource management thread at initialization, and enabling the resource management thread to allocate and recycle cache basic cell resources of all task identifications based on a buddy algorithm; a performance monitoring thread module configured to create one or more performance monitoring threads corresponding to the task identifications to monitor the task identifications after managing cache basic cell resources of all task identifications; The performance monitoring thread module is configured to create one or more performance monitoring threads for each task identifier after the cache basic unit resources are managed for all the task identifiers, so as to monitor the task identifiers; wherein the performance monitoring thread monitors whether the self-cleaning function of the task identifier is frequently triggered, so as to adjust the allocation of the cache basic unit accordingly. The cache strategy module is configured to receive the corresponding cache maintenance strategy provided for each task identifier information from the multi-level cache system. The performance monitoring thread monitors whether the self-cleaning function of the task identifier is frequently triggered, so as to adjust the allocation of the cache basic unit accordingly, and the corresponding process includes: determining whether the self-cleaning function of the task identifier is frequently triggered; specifically, if the number of cache basic units in the task identifier space is less than a set cleaning threshold, the self-cleaning function of the task identifier is triggered; if the frequency of triggering the self-cleaning function of the task identifier within a certain period exceeds a set threshold, the self-cleaning function of the task identifier is frequently triggered; otherwise, the self-cleaning function of the task identifier is not frequently triggered; if not frequently triggered, a certain number of cache basic units are released; if frequently triggered, it is determined whether there are surplus cache basic units; if there are surplus cache basic units, the task identifier whose self-cleaning function is frequently triggered is allocated with the surplus cache basic units; if there are no surplus cache basic units, the cleaning threshold is raised; after the cleaning threshold is raised, it is determined whether the self-cleaning function of the task identifier is frequently triggered; if still frequently triggered, the number of dirty bit cache basic unit resources cleaned up in each self-cleaning process is increased.

4. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the multi-level cache method based on the task identifier in any one of claims 1 to 2.

5. A multi-level cache terminal, characterized by, It includes: a processor and a memory; the memory is configured to store a computer program; the processor is configured to execute the computer program stored in the memory, so that the multi-level cache terminal executes the multi-level cache method based on the task identifier in any one of claims 1 to 2.

Images