Allocation scheduling method for cache address tags

Abstract

The invention discloses an allocation scheduling method for cache address tags, relates to the technical field of computer cache management, and is used for solving the problem of cache quota imbalance. According to the method, a label view driven by an access affiliation identifier and a label quota model are introduced into the last-level cache, modeling and binding are carried out on label target quotas, guaranteed quotas and limited quotas of different tasks in each cache group, and when the cache is missed, a candidate set is limited and replaced in combination with undermatched, normal and overmatched states; selecting a replacement object according to the label priority, the reuse degree and the short-lifetime label mark, and performing closed-loop adjustment on a quota parameter and the label priority by counting the hit rate, the replacement rate and the response time in a period, so that cache address label allocation is adaptively converged along with load change; the overall hit rate and the key service time delay stability under the multi-tenant and mixed load scenes are considered, and the utilization rate of the last-level cache resources and the system operation reliability are improved.

Description

Technical Field

[0001] This invention relates to the field of computer cache management technology, and more specifically, to a method for allocating and scheduling cache address tags. Background Technology

[0002] In multi-core processors and cloud computing platforms, multiple processing cores, virtual machines, and business instances share the last-level cache, achieving fast hits on main memory access through cache address tags. Existing technologies typically rely on traditional replacement strategies and static partitioning methods to regulate cache resources, such as replacement algorithms based on access frequency or access time, and cache partitioning mechanisms based on path number or address coloring. Starting from the overall hit rate and hardware structure constraints, these methods uniformly schedule the cache space to improve throughput and average response performance under general loads. Such solutions have become relatively mature engineering practices in single applications or stable load scenarios.

[0003] However, in real-world operating environments with multi-tenancy and mixed loads, existing cache management technologies have significant shortcomings in address label allocation and scheduling. On the one hand, label occupancy relationships are usually passively formed by local replacement strategies, lacking a label quota model with access ownership identifiers as the granularity. This makes it impossible to express the occupancy boundaries between different tasks at the cache group level, which can easily lead to a sudden surge in access ownership occupancy of labels in some cache groups, causing frequent evictions of other critical task working sets. On the other hand, existing solutions mostly maintain statistics on label hits, replacements, and response times at an overall or coarse-grained level, making it difficult to directly feed the statistical results back to label allocation and replacement decisions. They also cannot adaptively adjust label quotas and priorities according to load changes, resulting in insufficient cache resource utilization efficiency and service level guarantee capabilities. In scenarios where the last-level cache is shared, performance jitter and uncontrollable service latency are likely to occur. Summary of the Invention

[0004] To overcome the aforementioned shortcomings of the existing technology, the following solutions are proposed to address the problem of cache quota imbalance in the aforementioned background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for allocating and scheduling cached address labels includes the following steps: In the last-level cache controller, an access ownership identifier is attached to each cache access. The cache group index and address label are obtained based on the access address. A label view is maintained in each cache group. The label view records the address label, ownership identifier, and access status of the cache line. The label view is updated when a hit or replacement occurs. During system initialization or configuration changes, a tag quota model is established for each access owner identifier in each cache group based on the task type and service level. The tag quota model includes target quota, guaranteed quota, limit quota and tag priority, and is associated with access owner identifier and cache group index. When a cache miss occurs and a new tag needs to be inserted into the target cache group, the current access attributed to the tag occupied in the cache group is compared with the tag quota model based on the tag view statistics and the current status is divided into under-quota, normal, or over-quota status. Based on the status-limited replacement candidate set, in the under-allocation state, priority is given to retaining the minimum quota tags of other affiliations; in the over-allocation state, priority is given to selecting replacement objects from the current affiliation tags; in the normal state, the replacement objects are determined by comprehensively considering the tag priority and reusability of each affiliation tag, and the new tag and access affiliation identifier are written to the tag view. Within a preset statistical period, the tag hit rate, replacement status, and corresponding response time of each access belonging to each cache group are summarized. The target quota, minimum quota, limit quota, and tag priority in the tag quota model are adjusted according to preset rules, and the adjusted tag quota model is used in the cache access scheduling of the next statistical period.

[0006] Furthermore, maintaining a tag view for each cache group includes: Within each cache group, assign a tag record structure to each cache line and establish a tag view record table. The tag record structure includes at least the address tag value, access ownership identifier, most recent access timestamp, access count value, reuse flag, and reservation flag fields. When a cache access is hit, the most recent access timestamp in the tag record structure corresponding to the hit cache line is updated according to the current time. The access count value is incremented according to a preset rule. The reuse flag is updated according to the access count value and the time interval. The reuse flag represents the degree of reuse of the tag within a preset time window. When replacing or inserting a new cache line, update the address tag value in the tag record structure corresponding to the replacement position to the new tag, update the access ownership identifier to the current access ownership, initialize the most recent access timestamp to the current time, initialize the access count value to the preset initial value, and reset the reuse flag and retention flag to the initial state. After completing the hit update and replacement update, the number of tags occupied by each access attribution in each cache group is counted based on the access attribution identifier field in the tag view.

[0007] Furthermore, during system initialization or configuration changes, a tag quota model is established for each access ownership identifier in each cache group, including: Based on the task type, service level parameters, and the hit rate statistics, average response time indicators, and access intensity indicators collected during historical operations, calculate the basic quota ratio corresponding to each access attribution identifier. The target quota is determined based on the base quota ratio and the total number of available tags in each cache group. The target quota represents a reference value for the number of tags belonging to this access in the cache group. Set a minimum quota based on the target quota, and the minimum quota shall not be lower than the target quota minus the first quota offset. Set a limit quota based on the target quota. The limit quota shall not be lower than the target quota and shall not be higher than the upper limit of the total number of available tags in the corresponding cache group. Based on the service level and the latency sensitivity of the task type, a tag priority parameter is generated for each access owner identifier. The tag priority parameter is combined with the target quota, guaranteed quota, and limit quota to form a tag quota model, and the index is used for storage according to the access owner identifier and cache group index.

[0008] Furthermore, when a cache miss occurs and a new tag needs to be inserted into the target cache group, the current access attributed to the tag in that cache group is compared with the tag quota model based on the tag view statistics, and the current state is divided into under-allocation, normal, or over-allocation states. Specific steps include: Within the target cache group, the number of tags occupied by the current access is counted according to the tag view. Within a preset time window, the number of tag insertions and tag hits of the access in the cache group are accumulated, and the average number of tags occupied within the time window is calculated. The average number of tags occupied is compared with the minimum quota, target quota, and limit quota in the tag quota model. When the average number of tags occupied is less than the minimum quota, the current access belongs to the cache group and is classified as under-quota. When the average number of tags occupied exceeds the limit, the current access to this cache group will be classified as an over-provisioned state. When the average number of tags occupied is between the minimum quota and the limit quota, and the difference between the average number of tags and the target quota falls within the preset tolerance range, the current access status belonging to this cache group is classified as normal. Under-allocation, normal, and over-allocation states are used as state inputs in the label allocation and replacement scheduling process.

[0009] Furthermore, limiting the candidate set of replacements and determining the replacement object in the undermatch state includes: Within the target cache group, obtain the number of tags occupied by each access owner and the minimum quota value in the tag quota model from the tag view. Tag records of access owners whose number of tags occupied is less than or equal to the corresponding minimum quota value are not added to the replacement candidate set. Add the tag records of access owners whose tag usage exceeds the corresponding minimum quota value to the replacement candidate set; In the replacement candidate set, a replacement sorting key is constructed based on the tag priority parameter and reuse flag in the tag record. Tag records whose tag priority parameter belongs to a preset low priority level and whose reuse flag indicates that the reuse degree is at a preset low reuse level are arranged at the beginning of the replacement sorting key. Select the corresponding cache behavior replacement position for the tag record that is sorted first according to the replacement sort key, and write the new tag and the current access ownership identifier at the replacement position.

[0010] Furthermore, in the over-sizing state, limiting the replacement candidate set and determining the replacement object includes: Within the target cache group, select replacement candidate objects from the tag records corresponding to the currently accessed category in the tag view; For the tag record corresponding to the current access, calculate the access interval index based on the reuse mark and the most recent access timestamp; When there are at least two replacement candidates, the first replacement priority is set for the tag records marked with short lifespan tags in the replacement candidates, and the second replacement priority is set for the tag records not marked with short lifespan tags. The first replacement priority is higher than the second replacement priority, and the short lifespan tag records corresponding to the first replacement priority are arranged at the beginning of the replacement sort key. Select the cache behavior replacement position corresponding to the top-ranked tag record according to the replacement sort key, and write the new tag and the current access ownership identifier at the replacement position.

[0011] Furthermore, under normal circumstances, determining replacement targets by considering both tag priority and reusability includes: Within the target cache group, collect all access-related tag records from the tag view and exclude tag records marked as valid for retention. For the remaining tag records, calculate the access frequency per unit time based on the access count value and the preset time window length, and write the access frequency per unit time as the reuse degree calculation result into the reuse degree tag; A replacement scoring function is constructed based on the label priority parameter and the reuse mark. The label priority weight and the reuse weight in the replacement scoring function are combined according to a preset ratio to obtain the replacement score value corresponding to each label record. The tag records are sorted from highest to lowest according to the replacement score. The tag record with the highest replacement score is placed at the corresponding cache behavior replacement position, and the new tag and the current access ownership identifier are written at the replacement position.

[0012] Furthermore, the identification and limitations of short-life-span labels include: Within each cache group, based on the number of insertions, hits, and most recent access timestamp of each tag record in the tag view, the tag lifetime length and hit ratio are calculated, and tag records with a lifetime length less than a preset access threshold and a hit ratio lower than a preset hit threshold are marked as short-life tags. A short-lived tag counter is maintained in each cache group. The number of short-lived tags in the current cache group is counted based on the short-lived tags in the tag records. When the number of short-lived tags reaches the preset upper limit, replacement candidates are selected only from the short-lived tag records when performing tag allocation and replacement scheduling. Replacement candidates are not selected from non-short-lived tag records.

[0013] Furthermore, within a preset statistical period, the tag hit rate, replacement rate, and corresponding response time of each access belonging to each cache group are summarized, and the tag quota model is adjusted accordingly, including: For each access, a statistics register is set up in each cache group. The statistics register records the number of tag hits, the number of tag replacements, the average number of tag occupancy, and the number of access requests within the statistical period. At the end of the statistical period, the hit rate is calculated based on the number of times the tag is hit and the number of access requests, and the replacement rate is calculated based on the number of times the tag is replaced and the number of access requests. The average of the hit rate, replacement rate, and tag usage is compared with the response time index of the corresponding access and the preset parameter threshold. When the hit rate is lower than the lower limit of the hit rate and the response time index is higher than the upper limit of the response time, the target quota and the minimum quota of the access in the cache group tag quota model are increased and the limit quota is reduced accordingly. When the average number of tags occupied is higher than the target quota and the hit rate is lower than the preset hit threshold, the target quota and minimum quota of the access in the cache group tag quota model are reduced, and the limit quota or tag priority parameter is reduced accordingly. The updated label quota model is written back to storage and participates in label allocation and replacement scheduling in the next statistical period.

[0014] Furthermore, hotspot cache group detection and tag subgroup redirection include: Within each cache partition, a hotspot monitoring counter is set for each cache group. The hotspot monitoring counter records the number of label replacements and the duration of overspec status within a preset time window. When the number of label replacements exceeds the replacement threshold and the duration of overspec status exceeds the duration threshold, the corresponding cache group is marked as a hotspot cache group. Among other cache groups belonging to the same cache partition as the hot cache group, select the cache group whose tag replacement count is lower than the preset threshold and whose average tag usage is lower than the target quota as the subgroup, and establish a tag subgroup mapping table between the hot cache group and the subgroup. The tag subgroup mapping table records the hot cache group identifier, access ownership identifier and subgroup set. When the current access belongs to the hotspot cache group and a new tag needs to be inserted, the target subgroup is selected from the subgroup set according to the tag subgroup mapping table. The new tag and the current access belonging identifier are written to the corresponding cache line of the target subgroup. When performing tag lookup, for access belonging with tag subgroup mapping, tag matching is first performed in the hotspot cache group, and then tag matching is performed in each subgroup recorded in the tag subgroup mapping table.

[0015] The technical effects and advantages of the method for allocating and scheduling cached address tags in this invention are as follows: This invention introduces a tag view and tag quota model driven by access ownership identifiers into the last-level cache controller, and constructs a closed-loop allocation and scheduling mechanism that combines state partitioning, candidate constraints, replacement decisions and statistical feedback. This enables cache tag resources to no longer be passively occupied by local replacement strategies, but to be finely quota controlled and dynamically adjusted in each cache group according to task type and service level. The replacement candidate set is limited in the under-allocation, normal and over-allocation states respectively. The replacement object is selected by combining tag priority, reusability and short lifespan tag identification. This achieves quota isolation between different access ownership and self-constraint under hot access, and reduces the risk of high priority or long lifespan working sets being frequently flushed. Meanwhile, the target quota, guaranteed quota, limit quota, and tag priority are iteratively corrected by using the hit rate, replacement rate, and response time within the statistical period. This enables the cache address tag allocation to adaptively converge with load changes, comprehensively balancing the overall hit rate and the latency stability of critical business in multi-tenant and mixed load scenarios, thereby improving the utilization efficiency of the last-level cache resources and the reliability of system operation. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a method for allocating and scheduling cached address tags according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] In order to achieve the above objectives, Figure 1A schematic diagram of the structure of a method for allocating and scheduling cached address tags according to the present invention is given, which specifically includes the following steps; In the last-level cache controller, an access ownership identifier is attached to each cache access. The cache group index and address label are obtained based on the access address. A label view is maintained in each cache group. The label view records the address label, ownership identifier, and access status of the cache line. The label view is updated when a hit or replacement occurs. During system initialization or configuration changes, a tag quota model is established for each access owner identifier in each cache group based on the task type and service level. The tag quota model includes target quota, guaranteed quota, limit quota and tag priority, and is associated with access owner identifier and cache group index. When a cache miss occurs and a new tag needs to be inserted into the target cache group, the current access attributed to the tag occupied in the cache group is compared with the tag quota model based on the tag view statistics and the current status is divided into under-quota, normal, or over-quota status. Based on the status-limited replacement candidate set, in the under-allocation state, priority is given to retaining the minimum quota tags of other affiliations; in the over-allocation state, priority is given to selecting replacement objects from the current affiliation tags; in the normal state, the replacement objects are determined by comprehensively considering the tag priority and reusability of each affiliation tag, and the new tag and access affiliation identifier are written to the tag view. Within a preset statistical period, the tag hit rate, replacement status, and corresponding response time of each access belonging to each cache group are summarized. The target quota, minimum quota, limit quota, and tag priority in the tag quota model are adjusted according to preset rules, and the adjusted tag quota model is used in the cache access scheduling of the next statistical period.

[0019] Step 1: In the last-level cache controller, an access ownership identifier is attached to each cache access. The cache group index and address label are obtained based on the access address. A label view is maintained in each cache group. The label view records the address label, ownership identifier, and access status of the cache line. The label view is updated upon a hit or replacement. Specifically, the implementation is as follows: The processor chip has a last-level cache controller. The last-level cache controller is connected to multiple processing cores and the main memory control unit via a bus. Each time a processing core initiates an access request to the last-level cache, the instruction decoding unit or the memory management unit adds an access ownership identifier to the access request according to the current operating environment. The access ownership identifier can be at least one of the following: virtual machine identifier, process identifier, thread group identifier, or service level identifier. In this embodiment, the access ownership identifier is encoded using a fixed-length field and remains unchanged as the access request is passed along the bus to the last-level cache controller.

[0020] After receiving the access request, the last-level cache controller decomposes the access address according to the cache structure definition. The high-order field of the access address is used as the address tag value, the middle field is used as the cache group index, and the low-order field is used as the group offset. The address tag value is used to identify the main memory address range corresponding to the cache line, the cache group index is used to locate the target cache group in the cache array, and the group offset is used to determine the specific cache line location within the cache group. The access ownership identifier, cache group index, and address tag value are used as input information for subsequent tag view maintenance. Within each cache group, the last-level cache controller allocates a storage area as a tag view record table. The tag view record table consists of several tag record structures, and each tag record structure corresponds to a cache line. The tag record structure includes at least the address tag value field, the access ownership identifier field, the most recent access timestamp field, the access count value field, the reuse flag field, and the reservation flag field.

[0021] The address tag value field is used to store the address tag value corresponding to the data in the current cache line; the access ownership identifier field is used to store the access ownership identifier currently occupying this cache line; The most recently accessed timestamp field is used to record the time information of the most recently accessed cache line. The time information can be provided by the global time counter inside the last-level cache controller. The time counter increments sequentially according to the clock cycle. The access count value field is used to accumulate the number of times the cache line is accessed within a preset time window. The preset time window is provided by the configuration register and can be in units of a certain number of clock cycles or a certain number of cache accesses. The reuse level flag field is used to record the reuse level of the cache line within a preset time window. The reuse level is divided into levels based on a combination of access count value and time interval. The levels can be divided into high reuse, medium reuse and low reuse. The retention flag field is used to mark whether the cache line has retention rights in subsequent replacement processes. Retention rights are used to restrict the cache line from being selected as a replacement object under specific conditions.

[0022] The tag view record table can be stored in a dedicated static random access storage array configured in parallel with the cache array. The last-level cache controller accesses this storage array through an index to read or update the tag record structure.

[0023] When a cache access hits, the last-level cache controller locates the tag record structure of the hit cache line in the tag view record table of the corresponding cache group based on the cache group index and address tag value. It reads the current time from the global time counter, writes the current time into the most recent access timestamp field, increments the access count value field by one according to a preset rule, and updates the reuse flag field according to the correspondence between the current access count value and the preset time window.

[0024] The reuse flag can be updated using a threshold-based approach. For example, if the access count value is higher than a first threshold within a preset time window, the reuse flag is set to high reuse; if the access count value is between the first and second thresholds, the reuse flag is set to medium reuse; and if the access count value is lower than the second threshold, the reuse flag is set to low reuse. The first and second thresholds are provided by the configuration register. During the hit update process, if the current access ownership identifier matches an existing access ownership identifier in the tag record structure, the tag view does not change the access ownership identifier field. If, in other implementations, the same cache line is allowed to be occupied by different access ownership identifiers at different stages, then the access ownership identifier field can be replaced according to a strategy upon hit.

[0025] When a cache access misses and a new tag needs to be inserted into the target cache group, the last-level cache controller selects a replacement location for a cache line within the target cache group based on the replacement policy. After selection, it reads the tag record structure corresponding to the cache line, updates the address tag value field in the tag record structure to the newly calculated address tag value, updates the access ownership identifier field to the access ownership identifier carried by the current access request, writes the most recent access timestamp field to the current time, sets the access count value field to the preset initial access count value (which can be one or other configured values), sets the reuse flag field to the low reuse start state, and resets the retention flag field to the no-retention state.

[0026] After the field update is completed, the new tag is considered to have been inserted into the tag view of the corresponding cache group. After each hit update or replacement update is completed, the last-level cache controller can access the attribution identifier field in the tag view record table in the background or at the end of the statistical period. It can count the number of tag records corresponding to each accessed attribution identifier in each cache group and write the count result to a dedicated statistics register. The number of tags occupied in the statistics register will be used as input data for subsequent tag quota model comparison and the division of under-allocation, normal, and over-allocation states.

[0027] Through the above steps, the last-level cache controller can attach an access ownership identifier to each cache access without changing the physical structure of the cache, and maintain a label view within each cache group that reflects the address label, access ownership, and access status, providing complete basic data for subsequent label quota control and replacement scheduling.

[0028] Step 2: During system initialization or configuration changes, based on task type and service level, establish a tag quota model for each access owner identifier in each cache group. The tag quota model includes target quota, guaranteed quota, limit quota, and tag priority, and is associated with the access owner identifier and cache group index. The specific implementation is as follows: During the system power-on initialization phase or when a virtual machine deployment change, process group adjustment, or service level parameter update is detected, the management software first enumerates all access ownership identifiers in the current operating environment. The access ownership identifier can be a combination of virtual machine identifier, process identifier, thread group identifier, or service level identifier. Then, it writes the task type and service level parameters to the last-level cache controller through the configuration interface.

[0029] The task type indicates the business attribute corresponding to the access ownership identifier. The task type can be one of latency-sensitive task, throughput-priority task, or periodic control task. The service level parameter indicates the priority level of the access ownership identifier in the overall system, such as different service level tiers. For each access ownership identifier, the management software also obtains hit rate statistics, average response time indicators, and access intensity indicators from historical operation records or preset configurations. The hit rate statistics represent the ratio of the number of cache hits to the total number of accesses for the access ownership identifier in a historical time period. The average response time indicator represents the average completion time observed on the processor side for the request corresponding to the access ownership identifier. The access intensity indicator represents the number of cache accesses initiated by the access ownership identifier per unit time.

[0030] It should be noted that hit rate statistics, average response time metrics, and access intensity metrics can be stored in a statistics register or non-volatile configuration memory and read during initialization.

[0031] After obtaining the task type, service level parameters, hit rate statistics, average response time metrics, and access intensity metrics, the configuration logic in the management software or the last-level cache controller calculates the basic quota ratio for each access ownership identifier.

[0032] The base quota ratio reflects the relative share that the access attribution identifier should occupy in the overall cached tag resources. During the calculation process, weighting factors are assigned to the hit rate statistics, average response time metric, and access intensity metric, respectively. The weighting factors are given by the configuration register, and the calculation process can be performed in the following order: First, the access intensity contribution is obtained by comparing the access intensity index with the expected system load ratio. Then, the hit rate contribution is obtained by comparing the hit rate statistics with the expected hit rate range. Finally, the response time contribution is obtained by comparing the average response time index with the response time target range. Then, the three contributions are weighted and summed according to the weight factors to obtain a comprehensive score representing the caching demand of the access attribution identifier. The comprehensive score is then normalized with the comprehensive scores of other access attribution identifiers so that the sum of the basic quota ratios of all access attribution identifiers is one.

[0033] The expected load ratio, expected hit rate range, and target response time range are pre-set by the system design phase based on the application scenario and written to the last-level cache controller through the configuration register.

[0034] After obtaining the basic quota ratio, the last-level cache controller calculates the target quota, guaranteed quota, and limit quota for each cache group. For a certain cache group, the total number of available tags is equal to the number of cache lines in that cache group, denoted as a fixed integer. The target quota value is obtained by multiplying the total number of available tags by the base quota ratio of the corresponding access home identifier, and rounding it to an integer. The target quota represents a reference value for the number of tags that the access home identifier is expected to maintain in the cache group. The minimum quota is obtained by subtracting a first quota offset from the target quota. The first quota offset is a non-negative integer set by the configuration register and is used to control the interval between the minimum quota and the target quota. When the target quota minus the first quota offset is less than zero, the minimum quota is limited to zero. The limit quota is obtained by adding a second quota offset to the target quota. The second quota offset is a non-negative integer. When the target quota plus the second quota offset is greater than the total number of available tags, the limit quota is limited to the total number of available tags.

[0035] This ensures that the target quota, guaranteed quota, and limit quota form an ordered range within each cache group, with the guaranteed quota not exceeding the target quota and the target quota not exceeding the limit quota, thus ensuring clear numerical boundaries for subsequent state partitioning.

[0036] After establishing the target quota, guaranteed quota, and limit quota, a label priority parameter is determined for each access attribution identifier: The tag priority parameter is a discrete level value, which can be divided into several priority levels, such as high priority, medium priority and low priority, or more subdivision levels. The process of determining the tag priority parameter combines the service level parameter and task type information. For access attribution identifiers with higher service levels and latency-sensitive task types, a higher priority level is assigned. For task types with lower service levels or those primarily focused on throughput, lower priority tiers are assigned. The specific values ​​corresponding to the priority tiers are set through configuration registers and stored as integers within the last-level cache controller.

[0037] After calculating the target quota, guaranteed quota, limit quota, and tag priority parameters, the last-level cache controller establishes a tag quota model index table based on the access owner identifier and cache group index. In the index table, a tag quota model record is stored for each pair of access owner identifiers and cache group indexes. The tag quota model record contains the target quota, guaranteed quota, limit quota, and tag priority parameters corresponding to the pair of access owner identifiers and cache group indexes.

[0038] During subsequent cache access, the controller queries the corresponding record through the label quota model index table when making label allocation and replacement decisions, thereby performing label occupancy control and state division according to the label quota model established during initialization.

[0039] Step 3: When a cache miss occurs and a new tag needs to be inserted into the target cache group, the current access attributed to the tag in that cache group is compared with the tag quota model based on the tag view statistics. The current state is then classified as under-allocated, normal, or over-allocated. The specific implementation is as follows: Before executing tag allocation and replacement scheduling, the last-level cache controller first divides the tag occupancy status of the current access belonging to the target cache group according to the tag view and tag quota model. That is, in each cache group, an occupancy statistics structure is set up that corresponds one-to-one with each access belonging identifier. The occupancy statistics structure includes at least the current tag occupancy register, the cumulative tag occupancy register, the sampling count register, and the current status register.

[0040] The current tag occupancy register records the number of tag records occupied by this access in this cache group at the current moment. This value is counted and written by traversing the access ownership identifier field during the aforementioned tag view update process. The cumulative tag occupancy register records the sum of tag occupancy counts obtained from multiple samples within a preset time window, while the sampling count register records the number of samples completed within that preset time window. The preset time window can be defined by a configuration register as a certain number of cache accesses or a certain number of clock cycles. The start and end times of the window are managed by the time management logic within the last-level cache controller. After each cache access process, the controller reads the current tag occupancy count and adds this value to the cumulative tag occupancy count register. Simultaneously, it increments the value of the sampling count register. At the end of the time window, the controller evenly distributes the cumulative tag occupancy count across the sampling counts to obtain the average tag occupancy count within that time window, and uses this average tag occupancy count as one of the input parameters for state division.

[0041] When a cache access misses and the replacement policy determines that a new tag needs to be inserted into the target cache group, the last-level cache controller first reads the tag quota model record corresponding to the target cache group to which the access belongs, and obtains the target quota, minimum quota, and limit quota parameters from it. Simultaneously, it reads the average tag usage count and the current tag usage count stored in the usage statistics structure. In this embodiment, the average tag usage count and the current tag usage count can be used in combination: The average tag usage reflects the overall usage level over a period of time, while the current tag usage reflects the instantaneous usage level at the current moment. The controller compares the average tag usage with the minimum quota. When the average tag usage is less than the minimum quota, the controller writes an under-quota status flag to the current status register corresponding to the cache group to indicate that the current access belongs to. When the average tag usage is greater than the limit quota, the controller writes an over-quota status flag to the current status register. When the average tag usage is between the minimum quota and the limit quota, the controller continues to calculate the absolute value of the difference between the average tag usage and the target quota, and compares this absolute value of the difference with a preset tolerance range parameter. The preset tolerance range parameter is given by the configuration register and is used to characterize the difference range that can be considered equivalent to the target quota. When the absolute value of the difference does not exceed the preset tolerance range, the current status register is written with the normal status flag; when the absolute value of the difference exceeds the preset tolerance range and the average number of tags occupied is close to the minimum quota side, the status register can be written with the under-allocation status as needed, or directly classified into the under-allocation status; when the absolute value of the difference exceeds the preset tolerance range and the average number of tags occupied is close to the limit quota side, the status register can be written with the over-allocation status as needed, or directly classified into the over-allocation status.

[0042] In a simplified implementation, only three levels can be used: under-allocation, normal, and over-allocation. The under-allocation state is classified as the average number of tags occupied being less than the minimum quota, the over-allocation state is classified as the average number of tags occupied being greater than the limit quota, and the remaining cases within the preset tolerance range are classified as the normal state.

[0043] After the last-level cache controller completes the above state calculation, it stores the state flag in the current state register, the access ownership identifier, and the cache group index into the state index table. The state index table can use the same indexing method as the tag quota model index table. In the subsequent tag allocation and replacement scheduling process, when the controller needs to limit the replacement candidate set, it can directly read the status flag corresponding to the target cache group currently accessed in the status index table. If the status flag is under-specified, the candidate set construction rules under the under-specified state are adopted. If the status flag is over-specified, the candidate set construction rules under the over-specified state are adopted. If the status flag is normal, the candidate set construction rules under the normal state are adopted. In this way, the status division process and the replacement decision process are structurally separated. In implementation, the division of under-specified, normal, and over-specified states is completed through explicit comparison and level marking.

[0044] Step 4: Based on the status-based candidate set for replacement, in the under-allocation state, priority is given to retaining the minimum quota tags of other attributions; in the over-allocation state, priority is given to selecting replacement targets from the current attribution tags; in the normal state, the replacement targets are determined by comprehensively considering tag priority and reusability among all attribution tags. The new tags and access attribution identifiers are then written to the tag view. Specifically, the implementation is as follows: When the last-level cache controller performs tag allocation and replacement scheduling based on the aforementioned state division results, it first reads the state flag corresponding to the current access home identifier in the target cache group from the state index table. The state flag is one of the following: under-allocation, normal, or over-allocation.

[0045] The controller selects different replacement candidate set construction rules and replacement object determination rules based on the status flags. Before entering the replacement logic, the controller will traverse the tag view record table corresponding to the target cache group, collect information such as the access ownership identifier field, the statistical value of the number of tags occupied for each access ownership, and the minimum quota parameter, tag priority parameter, reuse flag, reservation flag and short lifespan tag flag in the tag quota model, and form an initial view of the candidate set in the internal register or temporary buffer. Subsequently, the controller filters the initial view based on the current state to obtain a set of replacement candidates that meet the constraints of the current state. It then performs sorting and selection operations on the replacement candidate set to finally determine the specific location for replacing the cached behavior and writes the new label and the current access ownership identifier into the corresponding label record structure in the label view record table.

[0046] When the current state is marked as under-allocation, the controller's goal is to replenish the number of tags occupied by the current access owner identifier while minimizing interference with the minimum quota tags of other access owner identifiers. To this end, the controller retrieves the tag occupancy statistics for each access owner identifier from the tag view record table of the target cache group, as well as the minimum quota parameter from the tag quota model record. Access owner identifiers with a tag occupancy number less than or equal to the corresponding minimum quota parameter are considered to be within the minimum range, and their corresponding tag record structures are not added to the replacement candidate set. Only the tag record structures corresponding to access owner identifiers with a tag occupancy number greater than the corresponding minimum quota parameter are added to the replacement candidate set.

[0047] After constructing the replacement candidate set, the controller reads the tag priority parameter and reuse flag of each tag record structure in the candidate set, and constructs the replacement sorting key according to the pre-configured sorting rules. The sorting rules can be set to arrange tag records with lower tag priority levels first. If the tag priorities are the same, the reuse flag indicates that the tag records with lower reuse levels are arranged first. The controller selects the cache behavior replacement position corresponding to the tag record with the highest sorting result according to the replacement sorting key order. At the replacement position, it writes the newly calculated address tag value and the current access ownership identifier field. At the same time, it initializes the most recent access timestamp field to the current time, resets the access count value field and reuse flag field to the initial state, resets the retention flag field to the unreserved state, and updates the number of tags occupied by each access ownership identifier in the cache group in the statistics register.

[0048] When the current state is marked as over-provisioned, the controller's goal is to reclaim the tag records occupied by the current access home identifier itself to avoid further encroaching on the quotas of other access home identifiers. Within the target cache group, the controller only selects replacement candidates from the tag record structure in the tag view record table where the access home identifier field is equal to the current access home identifier, and does not select replacement candidates from the tag record structure corresponding to other access home identifiers. For each tag record structure corresponding to the current access attribution identifier, the controller calculates access interval-related indicators based on the reuse flag and the most recent access timestamp. For example, based on the difference between the most recent access timestamp and the current time, and the relationship between the access count value and the time window length, tag records with long access intervals and low reuse are marked. When there are at least two replacement candidates, the controller first checks the short-lifetime tag marking field, sets a first replacement priority for tag records marked with short-lifetime tags, and sets a second replacement priority for tag records not marked with short-lifetime tags. The first replacement priority is higher than the second replacement priority. The short-lifetime tag records corresponding to the first replacement priority are arranged at the beginning of the replacement sort key. Then, among tag records with the same replacement priority, they are sorted according to the access interval-related indicators and the reuse flag, so that tag records with longer access intervals and lower reuse are placed in the first order.

[0049] The controller selects the corresponding cache behavior replacement position of the top-ranked tag record according to the sorting result, and performs the same operations as before: writing the new tag value and the current access ownership identifier, resetting the access count value and reuse flag, and updating the statistics register.

[0050] When the current state is marked as normal, the controller comprehensively considers the tag priority and reusability of each access ownership identifier within the target cache group to select a relatively fair replacement object. The specific steps include: The controller first collects all tag record structures corresponding to the access ownership identifier from the tag view record table, excludes tag record structures whose retention flag field is in a valid retention state, and includes the remaining tag record structures in the replacement candidate set.

[0051] For each tag record structure in the replacement candidate set, the controller calculates the access frequency per unit time using the access count field and a preset time window length. This unit time access frequency is then written as the reuse factor calculation result into the reuse factor flag field or updated in conjunction with the existing reuse factor flag field. After obtaining the tag priority parameter and reuse factor flag, the controller combines the tag priority and reuse factor according to a preset ratio to form a replacement scoring function. This function calculates a replacement score value for each tag record structure. The replacement score value can be obtained by first normalizing the tag priority parameter and reuse factor flag to a uniform level, and then summing them according to preset weights.

[0052] After obtaining the replacement score values ​​of all tag record structures, the controller sorts the replacement candidate set from high to low according to the replacement score values, determines the cache line corresponding to the tag record structure with the highest replacement score value as the replacement position, and performs operations such as writing a new tag, writing the current access ownership identifier, initializing the most recent access timestamp, setting the initial access count value and reuse flag, and resetting the retention flag on the cache line. Through the three branch processes described above, the final-level cache controller limits different sets of replacement candidates in the under-provision, over-provision, and normal states, and determines the replacement object according to the combination rules of tag priority and reusability. While writing new tags and access ownership identifiers, it simultaneously maintains tag views and statistical information, providing continuous basic data for subsequent quota adjustments and state divisions.

[0053] Step 5: Within a preset statistical period, summarize the tag hit rate, replacement rate, and corresponding response time for each access belonging to each cache group. Adjust the target quota, minimum quota, limit quota, and tag priority in the tag quota model according to preset rules, and participate the adjusted tag quota model in the cache access scheduling of the next statistical period. Specifically, the implementation is as follows: The final-level cache controller sets up a statistics register for each access ownership identifier and each cache group to record tag hits, tag replacements, and tag usage within a preset statistical period. The statistics register includes at least the following fields: tag hit count, tag replacement count, accumulated tag usage count, and number of access requests.

[0054] The tag hit count field records the number of times the access attribution identifier is hit in the corresponding cache group within the statistical period; the tag replacement count field records the number of times the access attribution identifier triggers a tag replacement operation in the corresponding cache group within the statistical period; the tag occupation quantity sum field records the sum of the tag occupation quantities obtained from multiple samplings within the statistical period; and the access request quantity field records the total number of access requests for the access attribution identifier pointing to the corresponding cache group within the statistical period.

[0055] It should be noted that the preset statistical period is given by the configuration register and can be defined as a fixed number of clock cycles, a fixed number of cache access requests, or a fixed time length. Within the statistical period, whenever an access owner accesses a cache group, the controller updates the statistical registers corresponding to the access owner and the cache group according to the access result. For example, when a hit occurs, the tag hit count field and the access request count field are incremented by one; when a replacement occurs, the tag replacement count field and the access request count field are incremented by one. Under the preset sampling rhythm, the current tag occupancy count value is read and accumulated into the tag occupancy count accumulation field.

[0056] At the end of each preset statistical period, the last-level cache controller starts the quota adjustment calculation logic, sequentially traversing all access ownership identifiers and all cache groups, reading the tag hit count, tag replacement count, accumulated tag usage value and access request count from the corresponding statistical register, and at the same time reading the response time index corresponding to the access ownership identifier from the performance monitoring unit or the upper-layer software interface. The response time index can be expressed as the average response time or the percentile of the response time for the access ownership identifier within the statistical period.

[0057] The controller obtains the hit rate by evenly distributing the number of tag hits across the number of access requests, the replacement rate by evenly distributing the number of tag replacements across the number of access requests, and the average number of tag occupancy by evenly distributing the cumulative value of tag occupancy across the number of samples within a preset statistical period. Subsequently, the controller compares the hit rate, replacement rate, average number of tags occupied, and response time metrics with the parameter thresholds preset in the configuration register. The parameter thresholds include at least the lower limit of hit rate, the upper limit of response time, and the hit threshold. Other threshold items can be added according to the application scenario. The lower limit of hit rate is used to distinguish whether the hit rate is too low, the upper limit of response time is used to distinguish whether the response time is too high, and the hit threshold is used to distinguish whether the hit rate does not reach the expected level.

[0058] During the comparison process, when the hit rate of a certain access attribution identifier on a certain cache group is lower than the lower hit rate limit and the response time metric is higher than the upper response time limit, the controller reads the access attribution identifier and the corresponding tag quota model record for that cache group from the tag quota model index table, and adjusts the target quota, guaranteed quota, and limit quota. The adjustment process can be executed in the following order: First, increase the target quota by a quota increment, which can be given by the configuration register and is a positive integer not exceeding the total number of available tags. Then, based on the new target quota, the guaranteed quota and the restricted quota are recalculated. The guaranteed quota is reduced by the first quota offset and limited to a value not less than zero. The restricted quota is increased by the second quota offset and limited to a value not greater than the total number of available tags. For access attribution identifiers with high service levels that have repeatedly shown low hit rates and high response times, the tag priority parameter can be increased by one priority level. In another scenario, when the average number of tags occupied is higher than the target quota and the hit rate is lower than the hit threshold, the controller will reduce the target quota by one quota reduction. The quota reduction can be equal to the aforementioned quota increment or configured separately, and the minimum quota and the limit quota will be recalculated based on the new target quota. For access ownership identifiers that have repeatedly shown a high average number of tags occupied and a low hit rate, their tag priority parameters can also be reduced, causing the tag priority parameters to drop by one priority level.

[0059] For access ownership identifiers that do not trigger any of the above conditions, the controller maintains their tag quota model records unchanged. By increasing or decreasing quotas and adjusting tag priority parameters based on conditions, the target quota, minimum quota, limit quota, and tag priority are discretized and adjusted according to the actual hit, replacement, and response situations within the statistical period.

[0060] After updating the tag quota model records for all access ownership identifiers and all cache groups, the last-level cache controller writes the updated tag quota model back to the storage unit corresponding to the tag quota model index table, and clears or resets the data fields related to the previous statistical period in the statistics register, preparing for the statistical work of the next statistical period. During subsequent cache access, when performing state partitioning and replacement candidate set constraints, the controller directly compares and sorts the adjusted target quota, minimum quota, limit quota, and tag priority parameters.

[0061] By limiting the adjustment process of the tag quota model to the boundaries of a preset statistical period, it ensures that the quota adjustment uses the summary information of the complete statistical period, while avoiding the introduction of additional complexity in a single access process. This allows the tag quota model to gradually converge to a configuration that better suits the characteristics of real-time access over multiple statistical periods.

[0062] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0063] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0064] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0065] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0066] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for allocating and scheduling cached address tags, characterized in that: The specific steps include: In the last-level cache controller, an access ownership identifier is attached to each cache access. The cache group index and address label are obtained based on the access address. A label view is maintained in each cache group. The label view records the address label, ownership identifier, and access status of the cache line. The label view is updated when a hit or replacement occurs. During system initialization or configuration changes, a tag quota model is established for each access owner identifier in each cache group based on the task type and service level. The tag quota model includes target quota, guaranteed quota, limit quota and tag priority, and is associated with access owner identifier and cache group index. When a cache miss occurs and a new tag needs to be inserted into the target cache group, the current access attributed to the tag occupied in the cache group is compared with the tag quota model based on the tag view statistics and the current status is divided into under-quota, normal, or over-quota status. Based on the status-limited replacement candidate set, in the under-allocation state, priority is given to retaining the minimum quota tags of other affiliations; in the over-allocation state, priority is given to selecting replacement objects from the current affiliation tags; in the normal state, the replacement objects are determined by comprehensively considering the tag priority and reusability of each affiliation tag, and the new tag and access affiliation identifier are written to the tag view. Within a preset statistical period, the tag hit rate, replacement status, and corresponding response time of each access belonging to each cache group are summarized. The target quota, minimum quota, limit quota, and tag priority in the tag quota model are adjusted according to preset rules, and the adjusted tag quota model is used in the cache access scheduling of the next statistical period.

2. The allocation and scheduling method for cached address tags according to claim 1, characterized in that: Maintaining a tag view for each cache group includes: Within each cache group, assign a tag record structure to each cache line and establish a tag view record table. The tag record structure includes at least the address tag value, access ownership identifier, most recent access timestamp, access count value, reuse flag, and reservation flag fields. When a cache access is hit, the most recent access timestamp in the tag record structure corresponding to the hit cache line is updated according to the current time. The access count value is incremented according to a preset rule. The reuse flag is updated according to the access count value and the time interval. The reuse flag represents the degree of reuse of the tag within a preset time window. When replacing or inserting a new cache line, update the address tag value in the tag record structure corresponding to the replacement position to the new tag, update the access ownership identifier to the current access ownership, initialize the most recent access timestamp to the current time, initialize the access count value to the preset initial value, and reset the reuse flag and retention flag to the initial state. After completing the hit update and replacement update, the number of tags occupied by each access attribution in each cache group is counted based on the access attribution identifier field in the tag view.

3. The allocation and scheduling method for cached address tags according to claim 1, characterized in that: During system initialization or configuration changes, a tag quota model is established for each access ownership identifier in each cache group, including: Based on the task type, service level parameters, and the hit rate statistics, average response time indicators, and access intensity indicators collected during historical operations, calculate the basic quota ratio corresponding to each access attribution identifier. The target quota is determined based on the base quota ratio and the total number of available tags in each cache group. The target quota represents a reference value for the number of tags belonging to this access in the cache group. Set a minimum quota based on the target quota, and the minimum quota shall not be lower than the target quota minus the first quota offset. Set a limit quota based on the target quota. The limit quota shall not be lower than the target quota and shall not be higher than the upper limit of the total number of available tags in the corresponding cache group. Based on the service level and the latency sensitivity of the task type, a tag priority parameter is generated for each access owner identifier. The tag priority parameter is combined with the target quota, guaranteed quota, and limit quota to form a tag quota model, and the index is used for storage according to the access owner identifier and cache group index.

4. The allocation and scheduling method for cached address tags according to claim 1, characterized in that: When a cache miss occurs and a new tag needs to be inserted into the target cache group, the current access attributed to the tag usage in that cache group, as statistically determined by the tag view, is compared with the tag quota model to classify the current state as under-quota, normal, or over-quota. Specific steps include: Within the target cache group, the number of tags occupied by the current access is counted according to the tag view. Within a preset time window, the number of tag insertions and tag hits of the access in the cache group are accumulated, and the average number of tags occupied within the time window is calculated. The average number of tags occupied is compared with the minimum quota, target quota, and limit quota in the tag quota model. When the average number of tags occupied is less than the minimum quota, the current access belongs to the cache group and is classified as under-quota. When the average number of tags occupied exceeds the limit, the current access to this cache group will be classified as an over-provisioned state. When the average number of tags occupied is between the minimum quota and the limit quota, and the difference between the average number of tags and the target quota falls within the preset tolerance range, the current access status belonging to this cache group is classified as normal. Under-allocation, normal, and over-allocation states are used as state inputs in the label allocation and replacement scheduling process.

5. The allocation and scheduling method for cached address tags according to claim 1, characterized in that: In the case of mismatch, the set of replacement candidates is limited and the replacement objects are determined to include: Within the target cache group, obtain the number of tags occupied by each access owner and the minimum quota value in the tag quota model from the tag view. Tag records of access owners whose number of tags occupied is less than or equal to the corresponding minimum quota value are not added to the replacement candidate set. Add the tag records of access owners whose tag usage exceeds the corresponding minimum quota value to the replacement candidate set; In the replacement candidate set, a replacement sorting key is constructed based on the tag priority parameter and reuse flag in the tag record. Tag records whose tag priority parameter belongs to a preset low priority level and whose reuse flag indicates that the reuse degree is at a preset low reuse level are arranged at the beginning of the replacement sorting key. Select the corresponding cache behavior replacement position for the tag record that is sorted first according to the replacement sort key, and write the new tag and the current access ownership identifier at the replacement position.

6. The allocation and scheduling method for cached address tags according to claim 1, characterized in that: Under over-provisioning conditions, the set of replacement candidates is limited and the replacement objects are determined, including: Within the target cache group, select replacement candidate objects from the tag records corresponding to the currently accessed category in the tag view; For the tag record corresponding to the current access, calculate the access interval index based on the reuse mark and the most recent access timestamp; When there are at least two replacement candidates, the first replacement priority is set for the tag records marked with short lifespan tags in the replacement candidates, and the second replacement priority is set for the tag records not marked with short lifespan tags. The first replacement priority is higher than the second replacement priority, and the short lifespan tag records corresponding to the first replacement priority are arranged at the beginning of the replacement sort key. Select the cache behavior replacement position corresponding to the top-ranked tag record according to the replacement sort key, and write the new tag and the current access ownership identifier at the replacement position.

7. The allocation and scheduling method for cached address tags according to claim 6, characterized in that: Under normal circumstances, the replacement targets are determined by considering both tag priority and reusability, including: Within the target cache group, collect all access-related tag records from the tag view and exclude tag records marked as valid for retention. For the remaining tag records, calculate the access frequency per unit time based on the access count value and the preset time window length, and write the access frequency per unit time as the reuse degree calculation result into the reuse degree tag; A replacement scoring function is constructed based on the label priority parameter and the reuse mark. The label priority weight and the reuse weight in the replacement scoring function are combined according to a preset ratio to obtain the replacement score value corresponding to each label record. The tag records are sorted from highest to lowest according to the replacement score. The tag record with the highest replacement score is placed at the corresponding cache behavior replacement position, and the new tag and the current access ownership identifier are written at the replacement position.

8. The allocation and scheduling method for cached address tags according to claim 7, characterized in that: The identification and limitations of short-life-span labels include: Within each cache group, based on the number of insertions, hits, and most recent access timestamp of each tag record in the tag view, the tag lifetime length and hit ratio are calculated, and tag records with a lifetime length less than a preset access threshold and a hit ratio lower than a preset hit threshold are marked as short-life tags. A short-lived tag counter is maintained in each cache group. The number of short-lived tags in the current cache group is counted based on the short-lived tags in the tag records. When the number of short-lived tags reaches the preset upper limit, replacement candidates are selected only from the short-lived tag records when performing tag allocation and replacement scheduling. Replacement candidates are not selected from non-short-lived tag records.

9. A method for allocating and scheduling cached address tags according to claim 8, characterized in that: Within a preset statistical period, the tag hit and replacement status of each access in each cache group, as well as the corresponding response time, are summarized, and the tag quota model is adjusted accordingly, including: For each access, a statistics register is set up in each cache group. The statistics register records the number of tag hits, the number of tag replacements, the average number of tag occupancy, and the number of access requests within the statistical period. At the end of the statistical period, the hit rate is calculated based on the number of times the tag is hit and the number of access requests, and the replacement rate is calculated based on the number of times the tag is replaced and the number of access requests. The average of the hit rate, replacement rate, and tag usage is compared with the response time index of the corresponding access and the preset parameter threshold. When the hit rate is lower than the lower limit of the hit rate and the response time index is higher than the upper limit of the response time, the target quota and the minimum quota of the access in the cache group tag quota model are increased and the limit quota is reduced accordingly. When the average number of tags occupied is higher than the target quota and the hit rate is lower than the preset hit threshold, the target quota and minimum quota of the access in the cache group tag quota model are reduced, and the limit quota or tag priority parameter is reduced accordingly. The updated label quota model is written back to storage and participates in label allocation and replacement scheduling in the next statistical period.

10. A method for allocating and scheduling cached address tags according to claim 9, characterized in that: Hotspot cache group detection and tag subgroup redirection include: Within each cache partition, a hotspot monitoring counter is set for each cache group. The hotspot monitoring counter records the number of label replacements and the duration of overspec status within a preset time window. When the number of label replacements exceeds the replacement threshold and the duration of overspec status exceeds the duration threshold, the corresponding cache group is marked as a hotspot cache group. Among other cache groups belonging to the same cache partition as the hot cache group, select the cache group whose tag replacement count is lower than the preset threshold and whose average tag usage is lower than the target quota as the subgroup, and establish a tag subgroup mapping table between the hot cache group and the subgroup. The tag subgroup mapping table records the hot cache group identifier, access ownership identifier and subgroup set. When the current access belongs to the hotspot cache group and a new tag needs to be inserted, the target subgroup is selected from the subgroup set according to the tag subgroup mapping table. The new tag and the current access belonging identifier are written to the corresponding cache line of the target subgroup. When performing tag lookup, for access belonging with tag subgroup mapping, tag matching is first performed in the hotspot cache group, and then tag matching is performed in each subgroup recorded in the tag subgroup mapping table.

Images