Resource management method, apparatus, device, storage medium, and program product

Abstract

The application relates to a resource management method, which comprises the following steps: running a test set using an initial configuration file, monitoring candidate performance loss events related to a target core cache of a target processor; determining a target hardware resource parameter associated with a target performance loss event with the highest current occurrence frequency from the initial configuration file; iteratively adjusting a parameter value of the target hardware resource parameter until convergence is achieved, so as to obtain a first intermediate state configuration file, with the aim of maximizing a performance yield rate; re-running the test set using the first intermediate state configuration file; if a write missing rate is higher than a preset threshold value or a new performance loss event occurs, adjusting a strategy parameter related to a write operation, so as to obtain a second intermediate state configuration file; re-running the test set using the second intermediate state configuration file; and re-executing the process of iteratively adjusting the parameter value of the target hardware resource parameter until convergence is achieved, so as to obtain a target configuration file. According to the method, system performance can be improved while resource utilization is optimized.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource management method, apparatus, device, storage medium, and program product. Background Technology

[0002] In computer system design, it's crucial to allocate resources appropriately for the processor's core cache to balance system performance and resource utilization, achieving optimal performance while minimizing resource waste. Traditional resource management solutions primarily utilize machine learning (ML) for core cache allocation. However, training ML models relies on large amounts of high-quality data, which in turn depends on simulations of large-scale standard test sets on a clock-accurate simulator. Therefore, the idea of ​​rapidly exploring the design space through ML contradicts the very premise of the concept. Furthermore, many ML models are "black boxes"—using test stimuli as input and performance metrics as output. This means that optimizing ML models depends on developers understanding the rationale behind the model's decisions, deviating from the fundamental principle that improving processor performance requires understanding the microarchitecture design. In conclusion, traditional machine learning-based resource management solutions fail to effectively balance system performance and resource utilization, and cannot achieve optimal performance while minimizing resource waste. Summary of the Invention

[0003] Therefore, it is necessary to provide a resource management method, apparatus, equipment, storage medium, and program product that can improve system performance while optimizing resource utilization, in order to address the aforementioned technical problems.

[0004] Firstly, this application provides a resource management method, the method comprising:

[0005] In a simulated environment of the target processor architecture, a test set is run using an initial configuration file, and at least one candidate performance loss event related to the target processor's in-core cache is monitored.

[0006] From the combination of microarchitectural parameters in the initial configuration file, determine the target hardware resource parameters associated with the target performance loss event that occurs most frequently at present;

[0007] With the goal of maximizing performance return rate, the parameter values ​​of the target hardware resource parameters are iteratively adjusted until convergence, thus obtaining the first intermediate configuration file;

[0008] If the test set is rerun using the first intermediate configuration file, and the write missing rate is higher than the preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain the second intermediate configuration file.

[0009] The test set is rerun using the second intermediate configuration file, and the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters is re-executed. After convergence, a target configuration file containing the final combination of microarchitecture parameters is obtained.

[0010] In one embodiment, the step of iteratively adjusting the parameter values ​​of the target hardware resource parameters until convergence, with the goal of maximizing performance yield, to obtain a first intermediate configuration file includes:

[0011] The parameter values ​​of the target hardware resource parameters are doubled, the test set is run using the configuration file corresponding to the doubled parameter values, and the target performance loss events are monitored.

[0012] If the target performance loss event is detected to be not eliminated, the step of doubling the parameter value of the target hardware resource parameter is repeated until the target performance loss event is eliminated, and the parameter value of the target hardware resource parameter when the target performance loss event is eliminated for the first time is recorded.

[0013] Starting from the parameter value of the target hardware resource parameter that first eliminates the target performance loss event, the parameter value of the target hardware resource parameter is continuously decreased and adjusted.

[0014] After each decrease, the test set is rerun and the performance gain under the current parameter configuration is calculated;

[0015] The parameter value of the target hardware resource parameter corresponding to the maximum performance gain is used as the current optimal parameter value of the target hardware resource parameter to obtain the first intermediate configuration file.

[0016] In one embodiment, the performance return rate includes absolute performance return rate and relative performance return rate; calculating the performance return rate under the current parameter configuration includes:

[0017] The absolute performance gain rate under the current parameter configuration is determined based on the ratio of the total number of first events to the total number of first resources; the total number of first events is the total number of events that have cumulatively reduced the target performance loss since the initial configuration; the total number of first resources is the total number of target hardware resources corresponding to the target hardware resource parameters that have been cumulatively increased under the current parameter configuration.

[0018] The relative performance gain under the current parameter configuration is determined based on the ratio of the total number of second events to the total number of second resources; the total number of second events is the total number of the target performance loss events reduced between two adjacent iterations under the current parameter configuration; the total number of second resources is the total number of the target hardware resources increased between two adjacent iterations.

[0019] In one embodiment, the step of using the parameter value of the target hardware resource parameter corresponding to the maximum performance gain as the parameter value of the current optimal target hardware resource parameter to obtain a first intermediate configuration file includes:

[0020] If the absolute performance yield is greater than or equal to the resource acceptable threshold, the current parameter configuration is determined to meet the convergence condition, and the current parameter value of the target hardware resource parameter is taken as the current optimal parameter value of the target hardware resource parameter to obtain the first intermediate configuration file; the resource acceptable threshold is set based on the maximum acceptable total amount of the first resource.

[0021] If the absolute performance yield is less than the acceptable resource threshold, the parameter values ​​of the target hardware resource parameters are continuously decreased and adjusted. The parameter value of the target hardware resource parameters that satisfies the preset convergence condition and corresponds to the maximum relative performance yield is taken as the current optimal parameter value of the target hardware resource parameters to obtain the first intermediate configuration file.

[0022] In one embodiment, if the write miss rate exceeds a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain a second intermediate configuration file, including:

[0023] If the write hit strategy parameter in the microarchitecture parameter combination is configured as WRITE_THROUGH, and the write miss rate is higher than a preset threshold or a new performance loss event occurs, then the write hit strategy parameter is adjusted from WRITE_THROUGH to WRITE_BACK to obtain the second intermediate configuration file.

[0024] In one embodiment, the target processor is a graphics processor; the target in-core cache is a level 1 data cache in the graphics processor.

[0025] The target performance loss event is any one of MISS_QUEUE_FULL, MSHR_MERGE_ENTRY_FAIL, and MSHR_ENTRY_FAIL.

[0026] If the target performance loss event is MISS_QUEUE_FULL, then the target hardware resource parameter is miss_queue_entries;

[0027] If the target performance loss event is MSHR_MERGE_ENTRY_FAIL, then the target hardware resource parameter is mshr_max_merge;

[0028] If the target performance loss event is MSHR_ENTRY_FAIL, then the target hardware resource parameter is mshr_entries.

[0029] Secondly, this application provides a resource management device, the device comprising:

[0030] The monitoring module is used to run a test set using an initial configuration file in a simulated environment of the target processor architecture and monitor at least one candidate performance loss event related to the target core cache of the target processor.

[0031] The determination module is used to determine the target hardware resource parameters associated with the most frequently occurring target performance loss event from the combination of microarchitectural parameters in the initial configuration file;

[0032] The adjustment module is used to iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence, with the goal of maximizing performance gain, to obtain a first intermediate configuration file; the test set is rerun using the first intermediate configuration file, and if the write miss rate is higher than a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain a second intermediate configuration file; the test set is rerun using the second intermediate configuration file, and the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters is re-executed, to obtain a target configuration file containing the final microarchitecture parameter combination after convergence.

[0033] Thirdly, this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the various method embodiments of this application.

[0034] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the various method embodiments of this application.

[0035] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps in the various method embodiments of this application.

[0036] The aforementioned resource management method, apparatus, device, storage medium, and program product, in a simulated environment of the target processor architecture, run a test set using an initial configuration file and monitor at least one candidate performance loss event related to the target processor's in-core cache; from the microarchitectural parameter combination of the initial configuration file, determine the target hardware resource parameters associated with the most frequently occurring target performance loss event; with the goal of maximizing performance gain, iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence, obtaining a first intermediate configuration file; rerun the test set using the first intermediate configuration file, and if the write miss rate exceeds a preset threshold or a new performance loss event occurs, adjust the policy parameters related to write operations in the microarchitectural parameter combination to obtain a second intermediate configuration file; rerun the test set using the second intermediate configuration file, and re-execute the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters, obtaining a target configuration file containing the final microarchitectural parameter combination after convergence. Compared to traditional resource management methods, this application directly addresses the root cause of performance bottlenecks through two-stage adaptive resource adjustment. In the first stage, through dynamic monitoring and attribution analysis based on performance loss events, key hardware resource parameters can be accurately located, and targeted, interpretable adjustments can be made around performance return rates. This process is completed in a closed loop in a simulation environment, avoiding the overhead of generating large amounts of training data and accelerating design space exploration. In the second stage, by treating key events such as write misses as independent optimization phases, the effectiveness and specificity of caching resource strategy adjustments are ensured. The method in this application achieves transparent and efficient resource allocation at the microarchitecture level, improving system performance while optimizing resource utilization. Attached Figure Description

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

[0038] Figure 1 This is a diagram illustrating the application environment of a resource management method in one embodiment;

[0039] Figure 2 This is a flowchart illustrating a resource management method in one embodiment;

[0040] Figure 3 This is a schematic diagram of an automatic fitting algorithm for key microarchitecture parameters in one embodiment;

[0041] Figure 4 This is a schematic diagram of a primary data cache access link with a missing data merging mechanism in one embodiment;

[0042] Figure 5 This is a detailed statistical diagram illustrating the failure events of L1D reserved items during the iteration process of an adaptive resource regulation strategy in one embodiment.

[0043] Figure 6 This is a schematic diagram illustrating the iterative effect of an automatic microarchitecture parameter fitting algorithm in one embodiment;

[0044] Figure 7 This is a schematic diagram illustrating the changes in the MSHE_QUEUE_FULL event with the depth of the MissQueue in one embodiment;

[0045] Figure 8 This is a detailed statistical diagram illustrating performance loss events during the iteration of an adaptive resource regulation strategy in one embodiment.

[0046] Figure 9 This is a schematic diagram illustrating the changes in performance loss events after the second stage of the adaptive control strategy is implemented in one embodiment.

[0047] Figure 10 This is a schematic diagram comparing the overall performance of the adaptive control strategy in the second stage of iteration in one embodiment;

[0048] Figure 11 This is a structural block diagram of a resource management device in one embodiment;

[0049] Figure 12 This is an internal structural diagram of a computer device in one embodiment;

[0050] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0052] The resource management method provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. The data storage system can be set up separately and can store the data that server 104 needs to process. The data storage system can be integrated into server 104 or placed in the cloud or on other servers. Terminal 102 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, vehicle terminals, etc. Server 104 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, cloud security, host security and other network security services, CDN, and basic cloud computing services such as big data and artificial intelligence platforms. Terminal 102 and server 104 can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0053] Server 104 can run a test set in a simulated environment of the target processor architecture using an initial configuration file obtained from terminal 102, and monitor at least one candidate performance loss event related to the target processor's in-core cache; determine the target hardware resource parameters associated with the most frequently occurring target performance loss event from the microarchitecture parameter combination of the initial configuration file; iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence with the goal of maximizing performance gain, and obtain a first intermediate configuration file; rerun the test set using the first intermediate configuration file, and if the write miss rate is higher than a preset threshold or a new performance loss event occurs, adjust the policy parameters related to write operations in the microarchitecture parameter combination to obtain a second intermediate configuration file; rerun the test set using the second intermediate configuration file, and re-execute the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters, and obtain a target configuration file containing the final microarchitecture parameter combination after convergence.

[0054] It is understood that this embodiment does not limit this aspect. Figure 1 The application scenarios shown are for illustrative purposes only and are not limited to these.

[0055] In one embodiment, such as Figure 2 As shown, a resource management method is provided. This method can be applied to computer devices, which can be terminals or servers. That is, the method can be executed independently by the terminal or the server, or it can be implemented through interaction between the terminal and the server. This embodiment illustrates the application of this method to a computer device as an example, including the following steps:

[0056] Step 202: In a simulation environment of the target processor architecture, run the test set using the initial configuration file and monitor at least one candidate performance loss event related to the target processor's in-core cache.

[0057] The target core cache of the target processor is any storage space in the target processor used for caching.

[0058] In one embodiment, the target processor can be any of a graphics processing unit (GPU), a central processing unit (CPU), an embedded microcontroller (MCU), a digital signal processor (DSP), an artificial intelligence accelerator (NPU, TPU), etc. For example, if the target processor is a graphics processing unit (GPU), then the target core cache can be the Level-1 Data Cache (L1D) in the GPU.

[0059] Step 204: Determine the target hardware resource parameters associated with the most frequently occurring target performance loss event from the microarchitectural parameter combination in the initial configuration file.

[0060] Here, target hardware resource parameters refer to the hardware resource parameters that cause the target performance loss event. Hardware resource parameters are the resource configuration parameters of the hardware resources in the target processor.

[0061] Specifically, the initial configuration file contains a combination of microarchitecture parameters, which consists of multiple microarchitecture parameters (i.e., hardware resource parameters). The computer device can identify the most frequently occurring target performance loss event from at least one monitored candidate performance loss event, and determine the target hardware resource parameters associated with that target performance loss event from the combination of microarchitecture parameters in the initial configuration file.

[0062] Step 206: With the goal of maximizing performance return, iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence, and obtain the first intermediate configuration file.

[0063] The first intermediate configuration file is a configuration file obtained by iteratively adjusting the parameter values ​​of the target hardware resources with the goal of maximizing performance gain until convergence. It can be understood that the first intermediate configuration file is an intermediate state and not the final configuration file.

[0064] In one embodiment, the computer device can maximize the performance return rate, iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence, record the parameter values ​​of the target hardware resource parameters at the time of convergence, update the initial configuration file based on the parameter values ​​of the target hardware resource parameters at the time of convergence, and obtain a first intermediate configuration file.

[0065] Step 208: Rerun the test set using the first intermediate configuration file. If the write missing rate is higher than the preset threshold or a new performance loss event occurs, adjust the strategy parameters related to write operations in the microarchitecture parameter combination to obtain the second intermediate configuration file.

[0066] Among these, a new performance loss event is a performance loss event other than the target performance loss event among at least one candidate performance loss event. The second intermediate configuration file is a configuration file obtained by adjusting the write operation-related strategy parameters in the microarchitectural parameter combination of the first intermediate configuration file. It can be understood that the second intermediate configuration file is an intermediate, non-final configuration file.

[0067] In one embodiment, the computer device can rerun the test set using a first intermediate profile, monitor the write miss rate, and continue to monitor at least one candidate performance loss event related to the target processor's in-core cache. If the write miss rate exceeds a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitectural parameter combination of the first intermediate profile are adjusted to obtain a second intermediate profile.

[0068] Step 210: Rerun the test set using the second intermediate configuration file and re-execute the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters. After convergence, obtain the target configuration file containing the final combination of microarchitecture parameters.

[0069] The target configuration file is the configuration file that the target processor will ultimately apply.

[0070] Specifically, the computer device can rerun the test set using the second intermediate configuration file and re-execute the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters, that is, re-execute the process of monitoring at least one candidate performance loss event related to the target core cache of the target processor; determine the target hardware resource parameters associated with the target performance loss event that occurs most frequently from the microarchitecture parameter combination of the initial configuration file; and iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence with the goal of maximizing the performance gain, and obtain the target configuration file containing the final microarchitecture parameter combination after convergence.

[0071] In the aforementioned resource management method, in a simulated environment of the target processor architecture, a test set is run using an initial configuration file, and at least one candidate performance loss event related to the target processor's core cache is monitored. From the microarchitecture parameter combinations in the initial configuration file, target hardware resource parameters associated with the most frequently occurring target performance loss event are determined. With the goal of maximizing performance gain, the parameter values ​​of the target hardware resource parameters are iteratively adjusted until convergence, obtaining a first intermediate configuration file. The test set is rerun using the first intermediate configuration file. If the write miss rate exceeds a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combinations are adjusted, obtaining a second intermediate configuration file. The test set is rerun using the second intermediate configuration file, and the iterative adjustment process of the target hardware resource parameter values ​​is re-executed. After convergence, a target configuration file containing the final microarchitecture parameter combinations is obtained. Compared to traditional resource management methods, this application directly addresses the root cause of performance bottlenecks through two-stage adaptive resource adjustment. In the first stage, through dynamic monitoring and attribution analysis based on performance loss events, key hardware resource parameters can be accurately located, and targeted and interpretable adjustments can be made around performance gain. This process is completed in a closed loop within a simulated environment, avoiding the overhead of generating large amounts of training data and accelerating design space exploration. In the second stage, by treating critical events such as write misses as independent optimization phases, the effectiveness and relevance of caching resource strategy adjustments are ensured. The method in this application achieves transparent and efficient resource allocation at the microarchitecture level, improving system performance while optimizing resource utilization.

[0072] In one embodiment, with the goal of maximizing performance gain, the parameter values ​​of the target hardware resource parameters are iteratively adjusted until convergence to obtain a first intermediate configuration file. This includes: doubling the parameter values ​​of the target hardware resource parameters; running a test set using the configuration file corresponding to the doubled parameter values ​​and monitoring for target performance loss events; if the target performance loss event is not eliminated, repeating the step of doubling the parameter values ​​of the target hardware resource parameters until the target performance loss event is eliminated, and recording the parameter values ​​of the target hardware resource parameters when the target performance loss event is first eliminated; starting from the parameter values ​​of the target hardware resource parameters when the target performance loss event is first eliminated, continuously decreasing the parameter values ​​of the target hardware resource parameters; rerunning the test set after each decrease and calculating the performance gain under the current parameter configuration; and using the parameter values ​​of the target hardware resource parameters corresponding to the maximum performance gain as the current optimal parameter values ​​of the target hardware resource parameters to obtain the first intermediate configuration file.

[0073] It is understandable that the step of iteratively adjusting the parameter values ​​of the target hardware resources until convergence, with the goal of maximizing performance gain, to obtain the first intermediate configuration file, integrates "coarse-grained adaptation" and "fine-grained control". Doubling the parameter values ​​of the target hardware resources is "coarse-grained adaptation", while continuously decreasing the parameter values ​​of the target hardware resources is "fine-grained control".

[0074] In one embodiment, the computer device may double the parameter value of the target hardware resource parameter (initial doubling), run the test set using the configuration file corresponding to the doubled parameter value, and monitor the target performance loss event; if the target performance loss event is detected to have been eliminated after the initial doubling, the parameter value of the target hardware resource parameter that first eliminated the target performance loss event is recorded, and the parameter value of the target hardware resource parameter is continuously decreased and adjusted starting from the parameter value of the target hardware resource parameter that first eliminated the target performance loss event; after each decrease, the test set is rerun, and the performance gain rate under the current parameter configuration is calculated; the parameter value of the target hardware resource parameter corresponding to the maximum performance gain rate is taken as the parameter value of the current optimal target hardware resource parameter to obtain the first intermediate configuration file.

[0075] In one embodiment, the parameter values ​​of the target hardware resource parameters are continuously reduced and adjusted. Specifically, the parameter values ​​of the target hardware resource parameters can be adjusted by continuously halving the resource increment.

[0076] In the above embodiments, a two-stage optimization strategy of "doubling-decreasing" is used to quickly locate the performance inflection point. First, aggressive expansion is used to quickly eliminate key performance bottlenecks and ensure the performance baseline; then, resources are rolled back in a more refined manner to optimize utilization. The entire process is precisely guided by performance yield and is completed automatically and efficiently in a simulation environment without relying on historical data or black-box models. It directly and interpretably achieves the optimal balance between system performance and resource utilization under specific performance loss events.

[0077] In one embodiment, the performance yield includes absolute performance yield and relative performance yield; calculating the performance yield under the current parameter configuration includes: determining the absolute performance yield under the current parameter configuration based on the ratio of the total number of first events to the total number of first resources; the total number of first events is the total number of target performance loss events that have been reduced since the initial configuration; the total number of first resources is the total number of target hardware resources corresponding to the target hardware resource parameters that have been increased cumulatively under the current parameter configuration; determining the relative performance yield under the current parameter configuration based on the ratio of the total number of second events to the total number of second resources; the total number of second events is the total number of target performance loss events that have been reduced between two adjacent iterations under the current parameter configuration; the total number of second resources is the total number of target hardware resources that have been increased between two adjacent iterations.

[0078] In one embodiment, the absolute performance rate of return and the relative performance rate of return can be calculated using the following formulas:

[0079] ;

[0080] in, Indicates absolute performance rate of return. Indicates relative performance rate of return. This indicates the current iteration round, and i represents the parameter currently being controlled. This represents the total number of target performance loss events under the initial configuration. This represents the total number of target performance loss events under the current parameter configuration. This represents the total number of target performance loss events under the previous parameter configuration. Indicates the total amount of the first event. Indicates the total amount of the first resource. Indicates the total amount of the second event. This indicates the total amount of target hardware resources corresponding to the cumulative increase in target hardware resource parameters under the previous parameter configuration. This indicates the total amount of the second resource.

[0081] In the above embodiments, the use of both "absolute" and "relative" performance-benefit quantification standards enables precise global and local evaluation of resource optimization. Absolute return on investment ensures optimal overall returns on resource input since the baseline; relative return on investment keenly captures the immediate efficiency of each marginal adjustment, preventing ineffective expansion with diminishing returns. By guiding the iterative process with both "absolute" and "relative" performance-benefit metrics, the system can converge from a global perspective to an efficient allocation range while also performing refined local optimization, ensuring that each increase in resources yields maximum performance improvement, thereby achieving an optimal balance between performance and resource utilization.

[0082] In one embodiment, the parameter value of the target hardware resource parameter corresponding to the maximum performance gain is used as the parameter value of the current optimal target hardware resource parameter to obtain a first intermediate configuration file. This includes: if the absolute performance gain is greater than or equal to a resource acceptable threshold, then determining that the current parameter configuration meets the convergence condition, and using the parameter value of the current target hardware resource parameter as the parameter value of the current optimal target hardware resource parameter to obtain a first intermediate configuration file; the resource acceptable threshold is set based on the maximum acceptable first total resource amount; if the absolute performance gain is less than the resource acceptable threshold, then continuously decreasing and adjusting the parameter value of the target hardware resource parameter, and using the parameter value of the target hardware resource parameter that meets the preset convergence condition and corresponds to the maximum relative performance gain as the parameter value of the current optimal target hardware resource parameter to obtain a first intermediate configuration file.

[0083] The preset convergence condition can be that the number of target performance loss events drops to zero or below a preset event elimination threshold.

[0084] In the above embodiments, by introducing a resource acceptable threshold and a dual convergence mechanism, a clear quantitative termination boundary is set for resource optimization. When the absolute rate of return on resource investment reaches the target, convergence is rapid, ensuring the efficiency of overall resource expansion. If the target is not reached, convergence is performed based on the optimal relative rate of return for each adjustment. In this way, the optimization speed and the quality of the final configuration can be intelligently and efficiently balanced.

[0085] In one embodiment, if the write miss rate is higher than a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain a second intermediate configuration file. This includes: if the strategy parameter of the write hit strategy in the microarchitecture parameter combination is configured as WRITE_THROUGH, and the write miss rate is higher than the preset threshold or a new performance loss event occurs, then the strategy parameter of the write hit strategy is adjusted from WRITE_THROUGH to WRITE_BACK to obtain a second intermediate configuration file.

[0086] In the above embodiments, a clear and efficient policy switching mechanism is provided for critical scenarios with high write miss rates. When a performance bottleneck is detected, it can automatically switch the write policy from write-through (WRITE_THROUGH) to write-back (WRITE_BACK), thereby effectively reducing memory access latency, eliminating related performance loss events, and improving cache utilization.

[0087] In one embodiment, such as Figure 3As shown, the iteration round is: iter; the acceleration decay factor is: alpha; whether it is the first iteration is: is_first_iter; whether the performance loss event is eliminated in the first iteration is: first_iter_cleaned_fails; whether fine-grained tuning has been applied is: fine_tune_applied; whether fine-grained tuning is applied for the first time is: is_first_time_fine_tune_applied; the total number of performance loss events obtained by regression with default configuration is: orig_total_fails; and the total number of performance loss events obtained after each iteration is: curr_total_fails. Specifically, in a simulation environment of the target processor architecture, a test set is run using an initial configuration file, and at least one candidate performance loss event related to the target processor's core cache is monitored. From the microarchitectural parameter combinations in the initial configuration file, target hardware resource parameters associated with the most frequently occurring target performance loss event are determined. The parameter values ​​of the target hardware resource parameters are doubled, and the test set is run using the configuration file corresponding to the doubled parameter values, while monitoring the target performance loss event. If the target performance loss event is detected to have been eliminated after the first doubling, the parameter value of the target hardware resource parameter that first eliminated the target performance loss event is recorded. Starting from the parameter value of the target hardware resource parameter that first eliminated the target performance loss event, the parameter value of the target hardware resource parameter is continuously decreased and adjusted. After each decrease, the test set is rerun, and the performance gain under the current parameter configuration is calculated. The parameter value of the target hardware resource parameter corresponding to the maximum performance gain is taken as the current optimal parameter value of the target hardware resource parameter to obtain the first intermediate configuration file. If the target performance loss event is detected and not eliminated, repeat the step of doubling the parameter value of the target hardware resource parameter until the target performance loss event is eliminated, and record the parameter value of the target hardware resource parameter when the target performance loss event is first eliminated; starting from the parameter value of the target hardware resource parameter when the target performance loss event is first eliminated, continuously decrease and adjust the parameter value of the target hardware resource parameter; after each decrease, rerun the test set and calculate the performance gain under the current parameter configuration; take the parameter value of the target hardware resource parameter corresponding to the maximum performance gain as the parameter value of the current optimal target hardware resource parameter to obtain the first intermediate configuration file.

[0088] In one embodiment, the target processor is a graphics processor; the target in-core cache is the L1 data cache in the graphics processor; the target performance loss event is any one of MISS_QUEUE_FULL, MSHR_MERGE_ENTRY_FAIL, and MSHR_ENTRY_FAIL; if the target performance loss event is MISS_QUEUE_FULL, then the target hardware resource parameter is miss_queue_entries; if the target performance loss event is MSHR_MERGE_ENTRY_FAIL, then the target hardware resource parameter is mshr_max_merge; if the target performance loss event is MSHR_ENTRY_FAIL, then the target hardware resource parameter is mshr_entries.

[0089] MISS_QUEUE_FULL indicates the missing queue is full; MSHR_MERGE_ENTRY_FAIL indicates MSHR merging failed; MSHR_ENTRY_FAIL indicates insufficient MSHR entries. miss_queue_entries indicates the queue depth. <mq>mshr_max_merge represents the maximum number of merges; mshr_entries represents the number of entries. MSHR represents the Missing Status Hold Register.

[0090] For MSHR_MERGE_ENTRY_FAIL, this type of L1D reservation failure event often occurs in scenarios with high-frequency merged access: the 32 threads in a GPU warp typically access adjacent addresses, and the Load StoreUnit (LSU) checks whether these addresses fall within the same aligned memory block (usually 128 bytes). If the condition is met, the LSU merges these 32 independent thread requests into a single memory transaction and sends it to L1D. Therefore, L1D only allocates one MSHR entry for requests from the same cacheline. If multiple Global Memory Access Read (GLOBAL_ACC_R) requests from a warp hit the same cache line, but the number of pending requests for that line exceeds the maximum number of merges (mshr_max_merge) per MSHR entry, MSHR_MERGE_ENTRY_FAIL will be triggered.

[0091] Regarding MISS_QUEUE_FULL, when an L1D access misses, the request enters the MissQueue and occupies one entry. When the buffer between L1 and L2 is not full and there is no structural conflict on the L2 access port, requests are popped from the MissQueue one by one and enter the buffer queue between L1 and L2. If L1D continuously experiences non-duplicate address misses and congestion occurs in the downstream of L1, requests will accumulate in the MissQueue, ultimately resulting in the performance penalty of the MISS_QUEUE_FULL event.

[0092] Regarding MSHR_ENTRY_FAIL, it indicates that the MSHR queue has not been filled and the MSHR queue is full. "MSHR full" means that both "MSHR entries are full" and "the maximum number of mergeable entries for each MSHR entry has been reached". Even if the MissQueue is not full (!MISS_QUEUE_FULL) and each MSHR entry has not reached the maximum number of mergeable entries (!MSHR_MERGE_ENTRY_FAIL), the insufficient total number of MSHR entries can still become a bottleneck for outstanding writes.

[0093] In one embodiment, the GPU's core cache includes a Level-1 Data Cache (L1D), a Texture Cache, a Constant Cache, and an Instruction Cache within each Stream Multiprocessor (SM). These caches are located close to a large number of concurrently executing warps, providing the first line of defense against memory access latency.

[0094] L1D is generally both readable and writable, storing frequently accessed data on-chip to reduce accesses to the L2 cache and even video memory. In the Single Instruction Multiple Threads (SIMT) programming model, it processes merged memory requests in batches at the warp level.

[0095] Merging accesses is accomplished through the collaboration of the Missing Status Hold Register (MSHR) and the Miss Queue. The MSHR temporarily stores requests for missing cache lines at its current level and merges different requests before forwarding them to subsequent cache levels, thus saving bandwidth. Assuming cache accesses are at the sector level, the MSHR is indexed using sector-aligned addresses (e.g., 32-byte). Requests for different cache lines are temporarily stored in different MSHR entries, while the same MSHR entry stores requests for the same cache line from different SMs / WARPs, or requests for different sectors / bytes of the same cache line.

[0096] Each entry in the MSHR has a maximum number of mergeable entries (slot bits), which directly determines the upper limit of the number of outstanding requests in the pipeline. For example, if a write miss occurs and the current cache has not yet been serviced while a WARP issues a write request to the same address, a so-called write miss-under-miss occurs. If the wp:WRITE_BACK (B) + wap: LAZY_FETCH_ON_READ (L) combination strategy is used at this time, the current cache will not immediately send read requests to the subsequent cache to seek backfill. Instead, the MSHR will continue to take over these outstanding requests until the response from the subsequent cache is returned, thereby completing the backfilling of the current cache and deleting the MSHR entry.

[0097] When an L1D access miss occurs, the missing request first preempts a slot in the MSHR (Maximum Search Engine Registry). After successful preemption, the request is queued in the MissQueue, which then pushes entries to the Level-2 Cache (L2C) in sequence. The MSHR tracks outstanding miss information (MetaData), including the target address, the sector or byte to be returned, the warp list, whether a request has been sent to a lower level, write-back / replacement information, etc. The MissQueue carries the requests after L1D miss merging, serving as a buffer queue for sending requests.

[0098] In one embodiment, a first-level cache access chain with a missing cache merging mechanism, such as Figure 4 As shown, there are three main pathways:

[0099] (1) Request Path: The path from SM to private L1D, involving access to L1D. If L1D is not hit, then L1D MSHR is accessed further to generate a flag indicating whether MSHR is hit (mshr_hit) and whether it is not full (mshr_avail). If mshr_hit and mshr_avail, then an MSHR entry and a MissQueue entry are created simultaneously. As shown in the figure, assuming that at t=t0, the buffer queue in the Local Access Interface (LAI) flowing to the Local Network-on-Chip (LNOC) is not full, then the first entry of the MissQueue is put into the buffer queue, waiting for the request to be successfully arbitrated by LNOC before the request enters L2SG.

[0100] (2) Refill Path: The response path from the L1D to the subsequent cache. Responses from the L2 Sub-Group (L2SG) pass through the LNOC and LAI buffers and then enter the response buffer (response_buffer) inside the L1D. The response_buffer pushes out a request from the head of the queue sequentially and compares its address with the requests stored in MSHR. If a match is found, a slot (the head entry of m_list) is removed. If m_list is empty after the current slot is removed, the corresponding row in MSHR is deleted, and the head entry of the response_buffer is removed (releasing a response_buffer entry).

[0101] (3) Response Path: After each removal of the head entry of response_buffer, the head entry of MissQueue is pushed out. This entry is returned to the response buffer queue inside L1D and the L1D is backfilled at the appropriate time.

[0102] In one embodiment, the configuration parameters for the first-level data cache are described as follows: The configuration file gpgpusim.config, containing the microarchitecture parameters specific to each round of regression testing, is stored in the path specified in this round of regression. The L1D configuration line and default configuration are: -gpgpu_cache:dl1 S:4:128:64,L:T:m:L:L,A:512:8,16:0,32.

[0103] The above configuration field consists of three parts. The first part, separated by commas, is the configuration S:4:128:64, which sets the organization structure of L1D, indicating that L1D access is based on sector (Sectored: S), with a total of 4 sets, each cache line is 128 bytes, and the set associativity is 64.

[0104] The second part, L:T:m:L:L, specifies the strategy for accessing L1D, with parameters separated by colons representing the following:

[0105] 1. Replacement policy (rp), valid values ​​include: a) Least Recently Used (LRU), abbreviated as L; b) First In First Out (FIFO), abbreviated as F.

[0106] 2. Write policy (wp): a) Write-through (WRITE_THROUGH: T): Always write to the back-level cache; b) Read-only (READ_ONLY: R): The cache is not writable, and all store instructions need to bypass the cache; c) Write-back (WRITE_BACK: B): Only write back to the back-level cache when the cache line needs to be replaced; d) Write-eviction (WRITE_EVICT: E): After writing to the local cache, immediately evict the cache line to the back-level cache, and the local cache no longer keeps a copy of the line; e) Local write-back and global write-eviction (LOCAL_WB_GLOBAL_WE: L): A hybrid strategy, where each SM-initiated access uses the write-back policy, and access to global addresses uses the write-eviction policy.

[0107] 3. Label allocation strategy (ap): a) Allocation upon missing (ON_MISS: m); b) Allocation upon filling (ON_FILL: f).

[0108] 4. Write allocation policy (wap): a) No allocation for write (NO_WRITE_ALLOCATE: N): When a write miss occurs, no cache line is allocated; the request is immediately sent to the next level cache, and the current level cache remains unchanged. This is often used to prevent data that will only be used once after a write from filling the cache. b) Allocation for write (WRITE_ALLOCATE: W): When a write miss occurs, a cache line is immediately allocated. Simultaneously, a write request is sent to the next level cache, along with a request to read the entire cache line, to refill the current level cache. This strategy is for data that will be accessed repeatedly, ensuring that subsequent reads / writes of that line will hit. The cost is that after each write miss, the entire line must be fetched from the next level, putting significant pressure on the MissQueue and MSHR; c) Fetch cache line on write (FETCH_ON_WRITE: F): If the entire cache line is written, the next level cache is not read, and it is directly allocated in the current level cache and marked as dirty (MODIFIED); if it is a partial write, the write request is first registered in MSHR, then a read request is issued to fill in the remaining bytes, and then the current write value is merged. Compared with WRITE_ALLOCATE (W), this strategy can save the bandwidth occupied by one read operation when writing a complete cache line; if it is a partial write, the entire line of data still needs to be fetched first, and then the write update is performed, with the same performance as WRITE_ALLOCATE; d) Lazy loading on read (LAZY_FETCH_ON_READ: L): After each write miss, it needs to occupy a space in the current level cache and set a dirty (MODIFIED) / unreadable flag, until the next time the cache line is read, a read request is issued to fill in the remaining bytes. The advantage of this strategy is that if the data is written and never read, then the bandwidth for read-backflow is saved.

[0109] 5. Cache set index strategy (set index function: sif): a) Linear index (LINEAR_SET_FUNCTION: L): directly extract the set index from the input address as the index value; b) XOR (BITWISE_XOR_FUNCTION: X): XOR the high-order tag of the input address with the low-order set index as the set index value; c) Fermi hash function (FERMI_HASH_SET_FUNCTION): XOR the set index with the 13th, 14th, 15th, 17th, and 19th bits of the address, consistent with the actual NVIDIA Fermi hardware practice, aiming to alleviate the common set collision problem on Fermi under a certain number of sets; d) i-polynomial hash (HASH_IPOLY_FUNCTION: P): based on the pseudo-random polynomial (IPOLY) method proposed by Rau, mix the index bits according to the GF(2) polynomial, and achieve "theoretical collision avoidance" for all access patterns with a power of 2 step size; e) Custom function placeholder (CUSTOM_SET_FUNCTION: C).

[0110] The parameters in Part A:512:8,16:0,32 represent:

[0111] 1. MSHR type, A indicates the use of an associative organizational structure; 2. Total number of MSHR entries, default is 512; 3. Maximum number of merged entries allowed per MSHR entry, default is 8; 4. MissQueue depth, default is 16; 5. Result FIFO depth, not involved in typical L1D structures, setting it to 0 indicates that additional write-back result caching is not enabled; 6. Data port width, in bytes. The default configuration represents 32 bytes / cycle.

[0112] In one embodiment, the Rodinia SASS Benchmark is used as the regression test set, and GPGPU-Sim version 4.2.0, precisely calibrated for the NVIDIA Volta architecture, is used as the baseline design for the performance simulator. The test set contains 10 benchmarks: {backprop, bfs, hotspot, heartwall, lud, nw, nn, pathfinder, srad_v2, streamcluster}. Each benchmark contains multiple kernels, and each kernel is a GPU kernel function. The simulator captures the simulation configuration file gpgpusim.config in the regression directory to configure various microarchitecture parameters. The default L1D configuration is: -gpgpu_cache:dl1 S:4:128:64,L:T:m:L:L,A:512:8,16:0,32. Here, the depth of MissQueue is... <mq>=16. Maximum number of slots that can be merged in MSHR<mshr_max_merge> =8.

[0113] like Figure 5 As shown, each kernel in each benchmark is treated as having equal weight, and the total number of L1D retention failure events under each candidate configuration combination during the implementation of this application is counted. Figure 5 The first bar represents the statistical average of performance loss events for each benchmark when using the initial configuration file. The nw group is the most microarchitecture-friendly, and no L1D reserved item failures occurred even with the default configuration. After the initial application of the "coarse-grained adaptation" rules given by the "critical microarchitecture parameter adaptive fitting algorithm," the MSHR_MERGE_ENTRY_FAIL event was completely eliminated with mshr_max_merge=32. Figure 5 All configurations shown, except for base-config, fix mshr_max_merge at 32. (For...) <mq>Continuing to use the "coarse-grained adaptation" strategy, when <mq>When it grows to 64 ( Figure 5 As shown in the third column), the main factors causing reservation failures, MSHR_MERGE_ENTRY_FAIL and MISS_QUEUE_FULL, have been significantly reduced. <mq>When the number of benchmarks increased to 128, the L1D retention failure events for each benchmark, except for the streamcluster group, were completely eliminated.

[0114] In one embodiment, such as Figure 6 As shown, the most severe performance blocking event MISS_QUEUE_FULL that prevents outstanding requests from residing in the pipeline during in-kernel cache access is given, along with the depth of the corresponding configuration item missing queue. <mq>The relationship between them. Figure 6 .1 shows the plotting result after applying the "coarse-grained adaptation" strategy. It can be seen that when... <mq>After doubling from 256 to 512, all MISS_QUEUE_FULL events were eliminated. Therefore, <mq>=256 becomes the starting point for "fine-grained control". Figure 6 .2 and Figure 6 The commonality of .3 is the calculation of the rate of return on resource growth; the difference lies in: Figure 6 .2 Using the default configuration as the baseline, the statistics are based on absolute returns; Figure 6 .3 Statistical analysis focuses on the difference in returns between two consecutive trades. Figure 6 Further increase based on .2 Figure 6 The significance of .3 lies in revealing the pattern that continuing to increase resources after reaching the inflection point of yield will cause a sharp drop in average yield. (Compare with...) Figure 6 .2 and Figure 6 The three bars in the chart {288->320, 320->352, 352->384} of .3 show: <mq>The absolute return of 384, ror=190693.61, is higher than <mq>=320, the absolute return ror = 187063.26. However, in terms of relative return, resources from <mq>After increasing alpha by 2*alpha = 32 from a base value of 352, the ROR value is only 15104.12. The essence of this phenomenon is: <mq>When the value is 352, most of the MISS_QUEUE_FULL events have been eliminated.

[0115] In one embodiment, such as Figure 7 As shown: Using <mq>After reverting to the configuration of 352, the remaining unresolved MISS_QUEUE_FULL events are only 0.036 (483332.0 / 13366104.0) of the previous number, which is almost negligible. In other words, there is no longer any need to allocate valuable hardware resources to eliminate this small portion of MISS_QUEUE_FULL events; the optimal configuration given by the "fine-grained tuning" strategy is... <mq>=352.

[0116] In one embodiment, after comprehensively applying the adaptive parameter tuning strategy given by the "Adaptive Fitting Algorithm for Key Microarchitecture Parameters," the performance loss events MISS_QUEUE_FULL and MSHR_MERGE_ENTRY_FAIL are effectively suppressed. However, as... Figure 5 The last subplot of the streamcluster benchmark shows that MSHR_ENTRY_FAIL has become the primary issue. <mq>MSHR_ENTRY_FAIL appears starting from number 256, and with... <mq>As MSHR_ENTRY_FAIL increases, so does MSHR_ENTRY_FAIL. Figure 8 As shown, more detailed statistics are presented during the implementation of the adaptive control strategy. The second-to-last column reveals a similar pattern: from <mq>=64 cases of MSHR_ENTRY_FAIL increased sharply.

[0117] At this point, the "adaptive fitting algorithm enhancement" strategy is applied, and the write strategy is adjusted from WRITE_THROUGH to WRITE_BACK. To reveal the decrease in L1D bandwidth for L2C requests after the write strategy adjustment, Figure 9 The system now includes statistics on L2C access and bandwidth, expressed as a geometric mean. The statistics are performed in two steps: Step 1, each kernel within each benchmark is processed with equal weights, and the geomean of these kernels is calculated; Step 2, all benchmarks are processed with equal weights, and the geometric mean of the geomeans calculated in Step 1 is calculated again to obtain the final geomean shown in the table. Figure 9 This reflects the benefits brought about by the three changes:

[0118] 1. After the number of MSHR entries was doubled from the default 512, all MSHR_ENTRY_FAIL events added in the first phase of the iteration were eliminated (as shown in the line of the dse-iter-II-mshr-entries-1024 configuration item).

[0119] 2. After changing the write hit policy from WRITE_THROUGH to WRITE_BACK, the L2C access bandwidth decreased by 38.2% (15.915GB / s -> 9.83GB / s); the global write event (GLOBAL_ACC_W) for L2C completely disappeared, and the corresponding total number of L2C accesses also decreased by 37.5% (14553 -> 9094) (as shown in the line containing the dse-iter-II-mshr-ent-1024-mq-ent-wp-wb configuration item).

[0120] 3. After reapplying the automatic fitting algorithm, the increased number of MSHR entries further strained the MissQueue. <mq>=1024 was eliminated. Further application of a "fine-grained control" strategy, in <mq>When the value is 768, the maximum yield can be guaranteed by eliminating the MISS_QUEUE_FULL event while ensuring the increase in the number of MissQueue entries.

[0121] In one embodiment, the final performance comparison results are as follows: Figure 10 As shown, the three types of events that cause L1D reservation failures also use the same Geomean statistical method as L2C-related performance events. It can be seen that the algorithm gives the final configuration combination { <mq>:768, <mshr_max_merge>:32, <mshr_entries>:1024, <wp>While ensuring maximum profitability for all aspects, IPC improved by 1.73% compared to the first phase (61.24->62.302); L2C access bandwidth decreased by 38.2% (15.915GB / s->9.83GB / s); global write events to L2C (GLOBAL_ACC_W) completely disappeared, and the total number of L2C accesses also decreased by 37.5% (14553->9094).

[0122] In the above embodiments, for the graphics processor's level 1 data cache, three key hardware congestion events (missing queue full, MSHR merge failure, and insufficient MSHR entries) are precisely mapped to specific core microarchitecture parameters (queue depth, maximum merge count, and number of entries). This allows the resource optimization process to directly link abstract performance events to adjustable hardware configurations, achieving a precise closed loop of problem localization and parameter tuning. By specifically adjusting these key resources, memory access congestion in the graphics processor core can be alleviated most directly and efficiently, thereby improving graphics processing performance.

[0123] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially, these steps are not necessarily executed in that order. Unless otherwise expressly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the above embodiments may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0124] Based on the same inventive concept, this application also provides a resource management device for implementing the resource management method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more resource management device embodiments provided below can be found in the limitations of the resource management method described above, and will not be repeated here.

[0125] In one embodiment, such as Figure 11 As shown, a resource management device 1100 is provided, which specifically includes:

[0126] The monitoring module 1102 is used to run a test set using an initial configuration file in a simulation environment of the target processor architecture and monitor at least one candidate performance loss event related to the target core cache of the target processor.

[0127] The determination module 1104 is used to determine the target hardware resource parameters associated with the most frequently occurring target performance loss event from the combination of microarchitectural parameters in the initial configuration file;

[0128] The adjustment module 1106 is used to iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence, with the goal of maximizing performance gain, to obtain a first intermediate configuration file; the test set is rerun using the first intermediate configuration file, and if the write miss rate is higher than a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain a second intermediate configuration file; the test set is rerun using the second intermediate configuration file, and the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters is re-executed, and a target configuration file containing the final microarchitecture parameter combination is obtained after convergence.

[0129] In one embodiment, the adjustment module 1106 is further configured to double the parameter values ​​of the target hardware resource parameters, run the test set using the configuration file corresponding to the doubled parameter values, and monitor the target performance loss event; if the target performance loss event is not eliminated, the step of doubling the parameter values ​​of the target hardware resource parameters is repeated until the target performance loss event is eliminated, and the parameter values ​​of the target hardware resource parameters that were first eliminated are recorded; starting from the parameter values ​​of the target hardware resource parameters that were first eliminated, the parameter values ​​of the target hardware resource parameters are continuously decreased; after each decrease, the test set is rerun, and the performance gain rate under the current parameter configuration is calculated; the parameter values ​​of the target hardware resource parameters corresponding to the maximum performance gain rate are taken as the parameter values ​​of the current optimal target hardware resource parameters to obtain the first intermediate configuration file.

[0130] In one embodiment, the performance yield includes absolute performance yield and relative performance yield; the adjustment module 1106 is further configured to determine the absolute performance yield under the current parameter configuration based on the ratio of the total number of first events to the total number of first resources; the total number of first events is the total number of target performance loss events that have been reduced since the initial configuration; the total number of first resources is the total number of target hardware resources corresponding to the target hardware resource parameters that have been increased cumulatively under the current parameter configuration; and to determine the relative performance yield under the current parameter configuration based on the ratio of the total number of second events to the total number of second resources; the total number of second events is the total number of target performance loss events that have been reduced between two adjacent iterations under the current parameter configuration; the total number of second resources is the total number of target hardware resources that have been increased between two adjacent iterations.

[0131] In one embodiment, the adjustment module 1106 is further configured to determine that the current parameter configuration meets the convergence condition if the absolute performance yield is greater than or equal to the resource acceptable threshold, and to use the parameter value of the current target hardware resource parameter as the parameter value of the current optimal target hardware resource parameter to obtain a first intermediate configuration file; the resource acceptable threshold is set based on the maximum acceptable first total resource amount; if the absolute performance yield is less than the resource acceptable threshold, the parameter value of the target hardware resource parameter is continuously decreased and adjusted, and the parameter value of the target hardware resource parameter that meets the preset convergence condition and corresponds to the maximum relative performance yield is used as the parameter value of the current optimal target hardware resource parameter to obtain a first intermediate configuration file.

[0132] In one embodiment, the adjustment module 1106 is further configured to adjust the strategy parameter of the write hit strategy from WRITE_THROUGH to WRITE_BACK if the strategy parameter of the write hit strategy in the microarchitecture parameter combination is configured as WRITE_THROUGH and the write miss rate is higher than a preset threshold or a new performance loss event occurs, thereby obtaining a second intermediate configuration file.

[0133] In one embodiment, the target processor is a graphics processor; the target in-core cache is the L1 data cache in the graphics processor; the target performance loss event is any one of MISS_QUEUE_FULL, MSHR_MERGE_ENTRY_FAIL, and MSHR_ENTRY_FAIL; if the target performance loss event is MISS_QUEUE_FULL, then the target hardware resource parameter is miss_queue_entries; if the target performance loss event is MSHR_MERGE_ENTRY_FAIL, then the target hardware resource parameter is mshr_max_merge; if the target performance loss event is MSHR_ENTRY_FAIL, then the target hardware resource parameter is mshr_entries.

[0134] The aforementioned resource management device, in a simulated environment of the target processor architecture, runs a test set using an initial configuration file and monitors at least one candidate performance loss event related to the target processor's core cache. From the microarchitecture parameter combinations in the initial configuration file, it determines the target hardware resource parameters associated with the most frequently occurring target performance loss event. With the goal of maximizing performance gain, iteratively adjusts the parameter values ​​of the target hardware resource parameters until convergence, obtaining a first intermediate configuration file. The test set is rerun using the first intermediate configuration file. If the write miss rate exceeds a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combinations are adjusted, obtaining a second intermediate configuration file. The test set is rerun using the second intermediate configuration file, and the iterative adjustment process of the target hardware resource parameters is repeated. After convergence, a target configuration file containing the final microarchitecture parameter combinations is obtained. Compared to traditional resource management methods, this application directly addresses the root cause of performance bottlenecks through two-stage adaptive resource adjustment. In the first stage, through dynamic monitoring and attribution analysis based on performance loss events, key hardware resource parameters can be accurately located, and targeted and interpretable adjustments can be made around the performance gain. This process is completed in a closed loop within a simulated environment, avoiding the overhead of generating large amounts of training data and accelerating design space exploration. In the second stage, by treating critical events such as write misses as independent optimization phases, the effectiveness and relevance of caching resource strategy adjustments are ensured. The method in this application achieves transparent and efficient resource allocation at the microarchitecture level, improving system performance while optimizing resource utilization.

[0135] Each module in the aforementioned resource management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0136] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 12 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a resource management method.

[0137] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 13 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a resource management method. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0138] Those skilled in the art will understand that Figure 12 and Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0139] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0140] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0141] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0142] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0143] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0144] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0145] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / wp> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq> < / mq>

Claims

1. A resource management method, characterized in that, The method includes: In a simulated environment of the target processor architecture, a test set is run using an initial configuration file, and at least one candidate performance loss event related to the target processor's in-core cache is monitored. From the combination of microarchitectural parameters in the initial configuration file, determine the target hardware resource parameters associated with the target performance loss event that occurs most frequently at present; With the goal of maximizing performance return rate, the parameter values ​​of the target hardware resource parameters are iteratively adjusted until convergence, thus obtaining the first intermediate configuration file; If the test set is rerun using the first intermediate configuration file, and the write missing rate is higher than the preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain the second intermediate configuration file. The test set is rerun using the second intermediate configuration file, and the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters is re-executed. After convergence, a target configuration file containing the final combination of microarchitecture parameters is obtained.

2. The method according to claim 1, characterized in that, The process of iteratively adjusting the parameter values ​​of the target hardware resource parameters until convergence, with the goal of maximizing performance yield, to obtain a first intermediate configuration file, includes: The parameter values ​​of the target hardware resource parameters are doubled, the test set is run using the configuration file corresponding to the doubled parameter values, and the target performance loss events are monitored. If the target performance loss event is detected to be not eliminated, the step of doubling the parameter value of the target hardware resource parameter is repeated until the target performance loss event is eliminated, and the parameter value of the target hardware resource parameter when the target performance loss event is eliminated for the first time is recorded. Starting from the parameter value of the target hardware resource parameter that first eliminates the target performance loss event, the parameter value of the target hardware resource parameter is continuously decreased and adjusted. After each decrease, the test set is rerun and the performance gain under the current parameter configuration is calculated; The parameter value of the target hardware resource parameter corresponding to the maximum performance gain is used as the current optimal parameter value of the target hardware resource parameter to obtain the first intermediate configuration file.

3. The method according to claim 2, characterized in that, The performance return rate includes absolute performance return rate and relative performance return rate; the calculation of the performance return rate under the current parameter configuration includes: The absolute performance gain rate under the current parameter configuration is determined based on the ratio of the total number of first events to the total number of first resources; the total number of first events is the total number of events that have cumulatively reduced the target performance loss since the initial configuration; the total number of first resources is the total number of target hardware resources corresponding to the target hardware resource parameters that have been cumulatively increased under the current parameter configuration. The relative performance gain under the current parameter configuration is determined based on the ratio of the total number of second events to the total number of second resources; the total number of second events is the total number of the target performance loss events reduced between two adjacent iterations under the current parameter configuration; the total number of second resources is the total number of the target hardware resources increased between two adjacent iterations.

4. The method according to claim 3, characterized in that, The step of using the parameter value of the target hardware resource parameter corresponding to the maximum performance gain as the current optimal parameter value of the target hardware resource parameter to obtain the first intermediate configuration file includes: If the absolute performance yield is greater than or equal to the resource acceptable threshold, the current parameter configuration is determined to meet the convergence condition, and the current parameter value of the target hardware resource parameter is taken as the current optimal parameter value of the target hardware resource parameter to obtain the first intermediate configuration file; the resource acceptable threshold is set based on the maximum acceptable total amount of the first resource. If the absolute performance yield is less than the acceptable resource threshold, the parameter values ​​of the target hardware resource parameters are continuously decreased and adjusted. The parameter value of the target hardware resource parameters that satisfies the preset convergence condition and corresponds to the maximum relative performance yield is taken as the current optimal parameter value of the target hardware resource parameters to obtain the first intermediate configuration file.

5. The method according to claim 1, characterized in that, If the write miss rate exceeds a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain a second intermediate configuration file, including: If the write hit strategy parameter in the microarchitecture parameter combination is configured as WRITE_THROUGH, and the write miss rate is higher than a preset threshold or a new performance loss event occurs, then the write hit strategy parameter is adjusted from WRITE_THROUGH to WRITE_BACK to obtain the second intermediate configuration file.

6. The method according to claim 1, characterized in that, The target processor is a graphics processing unit (GPU); the target core cache is the level 1 data cache in the GPU. The target performance loss event is any one of MISS_QUEUE_FULL, MSHR_MERGE_ENTRY_FAIL, and MSHR_ENTRY_FAIL. If the target performance loss event is MISS_QUEUE_FULL, then the target hardware resource parameter is miss_queue_entries; If the target performance loss event is MSHR_MERGE_ENTRY_FAIL, then the target hardware resource parameter is mshr_max_merge; If the target performance loss event is MSHR_ENTRY_FAIL, then the target hardware resource parameter is mshr_entries.

7. A resource management device, characterized in that, The device includes: The monitoring module is used to run a test set using an initial configuration file in a simulated environment of the target processor architecture and monitor at least one candidate performance loss event related to the target core cache of the target processor. The determination module is used to determine the target hardware resource parameters associated with the most frequently occurring target performance loss event from the combination of microarchitectural parameters in the initial configuration file; The adjustment module is used to iteratively adjust the parameter values ​​of the target hardware resource parameters until convergence, with the goal of maximizing performance gain, to obtain a first intermediate configuration file; the test set is rerun using the first intermediate configuration file, and if the write miss rate is higher than a preset threshold or a new performance loss event occurs, the strategy parameters related to write operations in the microarchitecture parameter combination are adjusted to obtain a second intermediate configuration file; the test set is rerun using the second intermediate configuration file, and the process of iteratively adjusting the parameter values ​​of the target hardware resource parameters is re-executed, to obtain a target configuration file containing the final microarchitecture parameter combination after convergence.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images