GPU server resource dynamic allocation management method, device, equipment and media

Abstract

This invention relates to the field of computing resource scheduling technology, specifically to a method, apparatus, device, and medium for dynamic allocation and management of GPU server resources. The method involves extracting jump paths to divide task migration segments, matching duplicate tasks within threads, filtering overlapping tasks by combining scheduling and dwell time, analyzing resource access trends to identify stable contention combinations, and generating a dynamic allocation list by associating address frequencies. This invention identifies the behavioral similarity between multiple tasks by extracting jump paths between tasks and performing repetition analysis. It accurately delineates densely overlapping intervals of task execution through the cross-mapping of task scheduling time and path dwell time. Combined with the derivative judgment method of shared resource access frequency change trends, it identifies task combinations with stable resource contention behavior. Based on the joint ranking of address access frequency and dwell time, it establishes a dynamic binding strategy between tasks and GPU address resources.

Description

Technical Field

[0001] This invention relates to the field of computing resource scheduling technology, and in particular to a method, apparatus, device, and medium for dynamic allocation and management of GPU server resources. Background Technology

[0002] The field of computing resource scheduling technology involves the allocation and management of various hardware resources in a computing environment, such as central processing units, graphics processing units, memory, and network bandwidth, including resource utilization optimization, task execution efficiency improvement, and system load balancing.

[0003] Among them, the dynamic allocation and management method of GPU server resources refers to the allocation of GPU computing resources in a server environment where multiple users share graphics processor resources through methods such as predefined quota static partitioning, so as to realize the control and scheduling of resources and solve the problem that GPU servers lack dynamic response mechanisms for resource allocation when facing concurrent access from multiple tasks and multiple users.

[0004] Existing technologies manage resources through static quota allocation, lacking the ability to capture dynamic changes in task behavior. In scenarios with concurrent access from multiple users, resource allocation often relies on predefined strategies and fails to adjust in real time based on differences in execution paths and resource contention between tasks. This results in structural vacancies in resource utilization, easily leading to situations where some tasks have insufficient resource usage within the scheduling window. For example, if task A and task B have overlapping scheduling times but access different resources, they may still be included in the same quota limit, causing a decrease in task execution efficiency. Furthermore, when resource-intensive tasks are concentrated, the lack of methods to analyze behavioral similarities and access trends makes it impossible to effectively determine resource allocation priorities, leading to frequent contention of hot address segments by multiple tasks and affecting overall GPU performance. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method, apparatus, device, and medium for dynamic allocation and management of GPU server resources.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a method for dynamic allocation and management of GPU server resources, comprising the following steps:

[0007] S1: Obtain the instruction scheduling records of all tasks within the GPU scheduling cycle, extract the jump path sequence of each instruction from one position to the next position, and divide the task instruction migration path segments.

[0008] S2: Pair up and combine task instruction migration path segments with the same thread number, determine the degree of duplication of migration behavior between tasks using the longest common subsequence algorithm, and mark the set of tasks with duplicate migration paths;

[0009] S3: Calculate the scheduling time of each repeated migration path task set and the total dwell time of all task instruction migration path segments. Compare the scheduling interval of the task with the time range of the GPU scheduling window to filter overlapping and dense task groups.

[0010] S4: Obtain the frequency of shared resource calls for each task in the overlapping and dense task group, determine the trend of shared resource access frequency changes among tasks, identify task combinations with stable trends, and obtain a set of tasks with stable resource contention trends.

[0011] S5: Associate the task set with stable resource contention trend with the address access frequency record within the GPU scheduling cycle, determine the allocation correspondence between task number and corresponding address segment, and obtain the dynamic allocation list of GPU task resources.

[0012] As a further aspect of the present invention, the task instruction migration path segment includes a jump path segment number, instruction jump order position, and single segment dwell time; the repeated migration path task set includes a task-corresponding path segment sequence, path segment repetition value, and task pairing group identifier; the overlapping dense task group includes a task scheduling time period, GPU scheduling window position mapping value, and inter-task interval overlap ratio; the resource contention trend stable task set includes shared memory call change trend category, register call change trend category, and global storage access change trend category; and the GPU task resource dynamic allocation list includes a task number and address segment mapping relationship, address access frequency sorting result, and address allocation order index.

[0013] As a further aspect of the present invention, the step of obtaining the task instruction migration path segment specifically includes:

[0014] S111: Obtain the instruction scheduling records of all tasks within the GPU scheduling cycle, call the execution start position number, jump target position number and scheduling time corresponding to each instruction, organize adjacent jump paths in the order of scheduling time, and obtain the internal jump path sequence of the task.

[0015] S112: Based on the internal jump path sequence of the task, the segment boundary is determined according to the execution interval time between paths and the average dwell time within the task, and the jump path is divided to obtain the jump path division interval.

[0016] S113: Divide the interval according to the jump path, mark the segment number order, path number range and dwell time of each segment, and associate with the original task number information to obtain the task instruction migration path segment.

[0017] As a further aspect of the present invention, the step of obtaining the repeated migration path task set specifically includes:

[0018] S211: Obtain the task instruction migration path segment, classify it according to the thread number to which the task belongs, extract all tasks under the same thread number as combination candidates, pair up the task numbers of each pair of candidate tasks, and generate a task pairing sequence group within the thread.

[0019] S212: Extract the task pairing sequence group within the thread, extract the migration path segment number sequence of each pair of tasks, call the longest common subsequence algorithm, compare the path segment number order in the sequence bit by bit, obtain the length of the longest common subsequence of the path segment numbers, and use the ratio between the shorter of the two as the basis for judging the degree of repetition, and obtain the path segment repetition analysis result.

[0020] S213: Based on the path segment duplication analysis results, filter the task pairings with ratios exceeding the path segment duplication judgment benchmark value, identify the task set with close path segment duplication relationships, and obtain the duplicate migration path task set.

[0021] As a further aspect of the present invention, the step of obtaining the overlapping dense task group specifically includes:

[0022] S311: Obtain the scheduling time record of each task in the repeated migration path task set, extract the starting scheduling time of the task, call the dwell time of all path segments in the corresponding task instruction migration path segment data, calculate the total execution time of each task, and generate a task scheduling time dataset.

[0023] S312: Based on the task scheduling duration dataset, combine the start scheduling time and total task duration according to the task number, record the start and end positions and interval span of the time period for each task, and generate the task scheduling occupied interval.

[0024] S313: Based on the task scheduling occupancy interval information, obtain the time range of the GPU scheduling window, determine the scheduling interval overlap time period of each task, calculate the interval overlap ratio between two specified tasks, and filter the task combination with the interval overlap ratio greater than the scheduling overlap judgment benchmark value to obtain the overlapping dense task group.

[0025] As a further aspect of the present invention, the step of obtaining the resource contention trend stable task set specifically includes:

[0026] S411: Obtain the shared resource call data of each task in the overlapping dense task group, extract the shared memory access count, register call frequency and global storage access interval of the corresponding task, establish a resource type and access parameter correspondence structure according to the task number, and generate a shared resource call frequency dataset.

[0027] S412: Based on the shared resource call frequency dataset, with task number as the input order, the access frequency value of each type of shared resource is used as a variable dimension to input into the local weighted regression algorithm to fit the change trajectory of resource access frequency in the task number sequence, obtain the access frequency fitting curve of each type of resource in the task distribution, and generate the trend of shared resource access frequency change.

[0028] S413: Based on the trend of shared resource access frequency change, determine the first derivative of the fitted curve in the interval of all task numbers, and filter the task number group whose absolute value of the first derivative is lower than the benchmark value for judging resource access changes to obtain a set of tasks with stable resource contention trends.

[0029] As a further aspect of the present invention, the step of obtaining the GPU task resource dynamic allocation list specifically includes:

[0030] S511: Obtain the resource contention trend stable task set and address access frequency record data within the GPU scheduling cycle, extract the scheduling sequence number of each task and the dwell time of the task instruction migration path segment, establish the correspondence between task number, path segment dwell time and scheduling sequence, and generate a task resource access association parameter set.

[0031] S512: Based on the task resource access association parameter set, filter the address segments with the lowest access frequency value in all records as candidate mapping targets, sort them from largest to smallest according to the dwell time of the path segment corresponding to the task, and generate a task address priority allocation structure table.

[0032] S513: Based on the task address priority allocation structure table, bind the corresponding address segment start number to each task number in sequence to obtain the GPU task resource dynamic allocation list.

[0033] The GPU server resource dynamic allocation management device is used to execute the GPU server resource dynamic allocation management method, the GPU server resource dynamic allocation management device includes:

[0034] The path extraction and segmentation module obtains the instruction scheduling records of all tasks within the GPU scheduling cycle, extracts the jump path sequence of each instruction from one position to the next position, and divides the task instruction migration path segments.

[0035] The migration path duplication identification module pairs and combines the migration path segments of the task instructions with the same thread number, and uses the longest common subsequence algorithm to determine the degree of duplication of migration behavior between tasks, and marks the set of tasks with duplicate migration paths.

[0036] The scheduling interval overlap analysis module obtains the scheduling time of each repeated migration path task set and the total dwell time of all task instruction migration path segments to calculate the scheduling occupancy interval of the task, compares it with the time range of the GPU scheduling window, and filters out overlapping and densely overlapping task groups.

[0037] The resource access trend assessment module obtains the frequency of shared resource calls for each task in the overlapping and dense task group, determines the trend of shared resource access frequency changes among tasks, identifies task combinations with stable trends, and obtains a set of tasks with stable resource contention trends.

[0038] The address resource dynamic allocation module associates the resource contention trend stable task set with the address access frequency record within the GPU scheduling cycle, determines the allocation correspondence between task number and corresponding address segment, and obtains the GPU task resource dynamic allocation list.

[0039] A computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the GPU server resource dynamic allocation management device as described above.

[0040] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the GPU server resource dynamic allocation and management method described above.

[0041] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0042] In this invention, by extracting the jump paths between tasks and performing repetition analysis, the similarity of behaviors among multiple tasks is identified. By leveraging the cross-mapping between task scheduling time and path dwell time, the densely overlapping intervals of task execution are accurately defined. Combined with the derivative judgment method of the shared resource access frequency change trend, task combinations with stable distribution of resource contention behavior are identified. Based on the joint ranking of address access frequency and dwell time, a dynamic binding strategy between tasks and GPU address resources is established, realizing the optimized allocation of high-frequency access addresses. This effectively alleviates the resource contention bottleneck in concurrent task scheduling, improves resource utilization efficiency and scheduling accuracy, avoids address space conflicts and resource redundancy waste caused by static allocation, and enhances the response stability and scheduling flexibility of GPU servers when facing high-concurrency tasks. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the workflow of the present invention;

[0044] Figure 2 This is a detailed flowchart of S1 of the present invention;

[0045] Figure 3This is a detailed flowchart of the S2 process of the present invention;

[0046] Figure 4 This is a detailed flowchart of the S3 process of the present invention;

[0047] Figure 5 This is a detailed flowchart of the S4 process of the present invention;

[0048] Figure 6 This is a detailed flowchart of S5 of the present invention. Detailed Implementation

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

[0050] Please see Figure 1 This invention provides a technical solution: a method for dynamic allocation and management of GPU server resources, comprising the following steps:

[0051] S1: Obtain the instruction scheduling records of all tasks within the GPU scheduling cycle, extract the jump path sequence of each instruction from one position to the next position, and divide the task instruction migration path segments.

[0052] S2: Pair up and combine task instruction migration path segments with the same thread number, determine the degree of duplication of migration behavior between tasks using the longest common subsequence algorithm, and mark the set of tasks with duplicate migration paths;

[0053] S3: Calculate the scheduling time of each repeated migration path task set and the total dwell time of all task instruction migration path segments. Compare the scheduling interval of the task with the time range of the GPU scheduling window to filter overlapping and dense task groups.

[0054] S4: Obtain the frequency of shared resource calls for each task in the overlapping and dense task group, determine the trend of shared resource access frequency changes among tasks, identify task combinations with stable trends, and obtain a set of tasks with stable resource contention trends.

[0055] S5: Associate the task set with stable resource contention trend with the address access frequency record within the GPU scheduling cycle, determine the allocation correspondence between task number and corresponding address segment, and obtain the dynamic allocation list of GPU task resources;

[0056] The task instruction migration path segment includes the jump path segment number, instruction jump order position, and single segment dwell time. The repeated migration path task set includes the task corresponding path segment sequence, path segment repetition value, and task pairing group identifier. The overlapping and dense task group includes the task scheduling time period, GPU scheduling window position mapping value, and inter-task interval overlap ratio. The resource contention trend stable task set includes shared memory call change trend category, register call change trend category, and global storage access change trend category. The GPU task resource dynamic allocation list includes the task number and address segment mapping relationship, address access frequency sorting result, and address allocation order index.

[0057] Please see Figure 2 The specific steps for obtaining the task instruction migration path segment are as follows:

[0058] S111: Obtain the instruction scheduling records of all tasks within the GPU scheduling cycle, call the execution start position number, jump target position number and scheduling time corresponding to each instruction, organize adjacent jump paths in the order of scheduling time, and obtain the internal jump path sequence of the task.

[0059] To obtain the instruction scheduling records of all tasks within a GPU scheduling cycle, the GPU task scheduling log module must first be invoked to extract the instruction scheduling information for each GPU task, including the instruction number, execution start position number, jump target position number, and scheduling time. This information should be structured by converting it into a uniform array of structures, each containing four fields, and sorted in ascending order of scheduling time. Bubble sort or quicksort can be used for this sorting. After sorting, the jump paths of adjacent instructions are concatenated to form the task's path sequence. For example, if the instruction records for a task within a scheduling cycle are: Instruction 1 (start position 10, target position 20, scheduling time 10ms), Instruction 2 (start position 20, target position 35, scheduling time 15ms), Instruction 3 (start position 35, target position 60, scheduling time 20ms), the sorted path sequence is [10→20→35→60]. This path sequence is the jump path sequence for the task within the GPU scheduling cycle.

[0060] S112: Based on the internal jump path sequence of the task, the segment boundary is determined according to the execution interval between paths and the average dwell time within the task, and the jump path is divided to obtain the jump path division interval.

[0061] Based on the internal jump path sequence of the task, it is necessary to first extract the execution interval time between paths, that is, calculate the difference in scheduling time between adjacent jump paths. For example, if the scheduling time of the previous path is 15ms and the scheduling time of the next path is 21ms, then the interval is 6ms. Simultaneously, it is necessary to calculate the average dwell time within the task. The dwell time can be calculated by summing the time differences between the instructions in all jump paths at the target position and the next starting position, and then dividing by the number of jump segments. If there are three paths with time differences of 3ms, 4ms, and 5ms respectively, then the average dwell time is (3+4) / (4ms+5ms+5ms). +5) / 3=4ms. Based on the interval judgment strategy, the interval time between paths is compared with the average dwell time. If the interval time is greater than 1.5 times the average dwell time (for example, if the average dwell time is 4ms, then the threshold is 6ms), then the path is considered to have a significant jump and should be divided into two segments. Otherwise, it is classified into the same segment. In a certain instance, the interval between paths is 2ms, 3ms, 7ms, 2ms, and 6ms respectively, and the average dwell time is 4ms. The jump path is divided into three segments: [Path 1-2-3], [Path 4], and [Path 5].

[0062] S113: Divide the interval according to the jump path, mark the segment number order, path number range and dwell time of each segment, and associate with the original task number information to obtain the task instruction migration path segment;

[0063] Divide the path into intervals based on the jump path, and sequentially label each segment with segment numbers, such as segment 1 for the first segment, segment 2 for the second segment, and so on. Record the path number range for each segment, such as segment 1 including path numbers 1 to 3, segment 2 including only path 4, and segment 3 including path 5. At the same time, calculate the dwell time within each segment by summing the dwell times between all jumps in each segment. For example, the dwell time for segment 1 is 3ms + 4ms = 7ms, for segment 2 it is 2ms, and for segment 3 it is 6ms. Then bind this segment information with the original task number. For example, if the task number is T005, the output will be: T005-segment 1 (path 1-3, dwell time 7ms), T005-segment 2 (path 4, dwell time 2ms), T005-segment 3 (path 5, dwell time 6ms). This structured data can completely represent the migration path segment information of the task.

[0064] Please see Figure 3 The specific steps for obtaining the task set for repeated migration paths are as follows:

[0065] S211: Obtain the task instruction migration path segment, classify the tasks according to their thread numbers, extract all tasks under the same thread number as combination candidates, pair up the task numbers of each pair of candidate tasks, and generate task pairing sequence groups within the thread.

[0066] After obtaining the task instruction migration path segments, it is necessary to classify them according to the thread number of each task. First, extract the task number corresponding to each migration path segment and map it to its corresponding thread number. For example, in tasks T001 to T005, T001, T003, and T004 belong to thread A, and T002 and T005 belong to thread B. The tasks under thread A can be organized into a candidate task set {T001, T003, T004}, and the tasks under thread B can be organized into another candidate task set {T002, T005}. Then, perform a pairwise pairing operation on the task numbers of each candidate task set. If there are 3 tasks under thread A, then C(3,2)=3 pairs can be formed: {(T001, T003), (T004, T005)}. For example, the pairing results for thread A are S_A={(T001, T003), (T001, T004), (T003, T004)}, and the pairing results for thread B are S_B={(T002, T005)}. The entire process requires the use of a structured mapping table to record the task number, thread number, and corresponding path segment sequence. By traversing the candidate tasks through nested loops and forming pairing relationships, it is ensured that there are no duplicates between pairing groups and that the threads belong to the same group, thus forming the basic data for comparing task migration path segments.

[0067] S212: Extract the task pairing sequence group within the thread, extract the migration path segment number sequence of each pair of tasks, call the longest common subsequence algorithm, compare the path segment number order in the sequence bit by bit, obtain the length of the longest common subsequence of the path segment numbers, and use the ratio between the shorter of the two as the basis for judging the degree of repetition, and obtain the path segment repetition analysis results.

[0068] After obtaining the task pairing sequence groups within a thread, a similarity analysis needs to be performed on the migration path segment number sequences in each pair of tasks. During execution, the complete migration path segment number sequence is first extracted from each task. For example, if the path segment number sequence corresponding to task T101 is [1, 3, 4, 5, 7] and the path segment number sequence corresponding to task T102 is [2, 3, 4, 6, 7], then these two tasks are paired as a group for comparison and analysis. Next, the longest common subsequence algorithm needs to be called to compare the two path segment number sequences bit by bit.

[0069] The longest common subsequence (LCS) is the longest subsequence between two sequences that can be aligned with the same elements while maintaining their original order. In the example above, the LCS of T101 and T102 is [3, 4, 7], and its length is 3. To quantify the degree of repetition between path segments of tasks, a basic repetition ratio is defined. The calculation formula is as follows:

[0070] ;

[0071] in, : Basic path segment repetition ratio, with a value range of [0, 1]. The larger the value, the higher the path repetition. The length of the longest common subsequence of two path segment number sequences, for example, in the example above. ; The number of path segments for shorter tasks out of the total number of path segment numbers. In this example, the path segments T101 and T102 are both 5 in length. Substituting the example values, we get: .

[0072] To more accurately identify the structural consistency of repetitive behaviors in path segment sequences, a positional weight adjustment parameter is introduced. This parameter is used to weight and adjust the degree of deviation in the position of a path segment within a sequence. It ensures that common path segments with closer order contribute more, exhibit more significant positional shifts, and have smaller ratios. The ratio is calculated using the following formula:

[0073] ;

[0074] in, The adjusted path segment repetition ratio, ranging from [0, 1], is used to determine the degree of repetition between tasks; As mentioned above, this indicates the length of the shorter path segment sequence in the two tasks being compared. : Length of the longest common subsequence; The first segment in the common path The index position of the item in the sequence of path segments in Task 1 (starting from 1); The first segment in the common path The index position of the item in the path segment sequence of Task 2; The deviation of the index position of the common path segment in the two tasks; The positional difference adjustment coefficient is primarily based on the actual impact of the consistency of the path segment's position in different tasks on structural repetition judgment. During GPU task scheduling, if the relative positional difference of the same path segment in two tasks is small, it usually means that their execution flow has a high degree of structural consistency, thus requiring a higher repetition weight. Conversely, if the same path segment appears in significantly different positions in different tasks, even if the content is the same, its scheduling path has a significant structural difference, requiring a reduction in its contribution to the overall repetition ratio. To achieve this adjustment goal, a positional difference adjustment coefficient is introduced, with a recommended range of 0.2 to 0.5. A value of 0.2 indicates that a large path segment positional offset is allowed, with high tolerance for structural differences, suitable for scenarios with relatively loose thread scheduling; a value of 0.5 only allows for higher repetition scores when path segments are close in position, suitable for applications with strict structural alignment requirements. In actual testing, it was found that when the average length of the task path segment is between 5 and 8, setting it to 0.3 can effectively distinguish between continuous path repetition and scattered path overlap. Therefore, it can be used as a general recommended value and is suitable for most GPU instruction migration structure analysis tasks.

[0075] Let task T101 = [1, 3, 4, 5, 7] and task T102 = [2, 3, 4, 6, 7]. The longest common subsequence is [3, 4, 7]. The corresponding index positions are: the 2nd, 3rd, and 5th positions in T101; and the 2nd, 3rd, and 5th positions in T102. Therefore... ,set up Substitute into the formula to calculate:

[0076] ;

[0077] If we change to another task pairing, such as T103=[1, 3, 5, 7], and T102 is still [2, 3, 4, 6, 7], its LCS is [3, 7]. In T103, it is the 2nd and 4th position, and in T102, it is the 2nd and 5th position, with position deviations of 0 and 1 respectively.

[0078] ;

[0079] First, the path segment number sequence of each task pair is extracted. The length of the common segment sequence between the two tasks is calculated using the longest common subsequence algorithm. This length is then compared with the length of the task with fewer path segments to determine the basic degree of repetition. To further consider the positional offset of path segments in the sequence, a position weight adjustment parameter is introduced. Each matching path segment is weighted according to its positional difference to obtain a repetition ratio, with a value ranging from 0 to 1. A higher value indicates stronger repetition. For example, the ratio of tasks T101 and T102 is 0.6, indicating relatively consistent structures; the ratio of T102 and T103 is 0.48125, indicating some overlap but weaker consistency. The benchmark value for repetition judgment is set at 0.6. This is based on the observation in actual GPU task scheduling path statistics that when two tasks both have 5 path segments, and there are 3 path segments with completely identical content and order, the calculated ratio is 0.6. Such structures typically have continuous migration regions and share execution flows in the scheduling graph, making them representative. Task pairs with a ratio below 0.6 have scattered path overlap points, large positional offsets, and insufficient structural similarity. Therefore, using 0.6 as the benchmark value for repetition detection can effectively distinguish the set of tasks with closely repeated paths.

[0080] S213: Based on the path segment duplication analysis results, filter the task pairings with ratios exceeding the path segment duplication judgment benchmark value, identify the task set with close path segment duplication relationships, and obtain the duplicate migration path task set;

[0081] After completing the path segment duplication analysis, the system will perform a unified filtering operation on the duplication ratio of task pairings within all threads. First, a baseline value for path segment duplication judgment is set, for example, 0.6. All task pairing records are traversed, and pairing entries with a ratio higher than the baseline value are extracted and their corresponding task numbers are recorded. For example, if the duplication ratio of (T101, T102) is 0.6, it meets the condition and is retained. If the ratio of (T102, T103) is 0.48125, it does not meet the filtering condition and is removed. Then, based on the retention... The remaining pairing relationships are used to organize groups of tasks with closely related path segments through clustering or set merging. For example, if (T101, T102), (T102, T104), and (T101, T104) all satisfy the ratio condition, then the three can be merged into a task set {T101, T102, T104}. Each set is a set of tasks with repeated migration paths. This process can be achieved through disjoint-set data structure or graph connected component analysis to output all task sets that satisfy structural consistency.

[0082] Please see Figure 4 The specific steps for obtaining overlapping and dense task groups are as follows:

[0083] S311: Obtain the scheduling time record of each task in the repeated migration path task set, extract the starting scheduling time of the task, call the corresponding task instruction to migrate the dwell time of all path segments in the migration path segment data, calculate the total execution time of each task, and generate a task scheduling time dataset.

[0084] After obtaining the set of repeated migration path tasks, the scheduling time records of each task need to be organized. First, the start scheduling time of each task is extracted from the task scheduling log. For example, the start time of task T201 is 100ms and that of T202 is 105ms. Then, based on the instruction migration path segment data corresponding to the task, the dwell time of each path segment is extracted. The dwell time can be the cumulative value of the dwell time of each instruction in the path segment. For example, if the dwell times of the five path segments of T201 are 3ms, 4ms, 2ms, 5ms, and 1ms respectively, then the total task duration is 3+4+2+5+1=15ms. Similarly, if the total dwell time of the path segments of T202 is 20ms, then the total task execution time is 20ms. In this way, the start scheduling time of each task and the cumulative dwell time of the path segments are statistically integrated to form a complete task scheduling duration dataset. Each record contains the task number, start scheduling time, and total task execution time.

[0085] S312: Based on the task scheduling duration dataset, combine the start scheduling time and total task duration according to the task number, record the start and end positions and interval span of the time period for each task, and generate the task scheduling occupied interval.

[0086] Based on the task scheduling duration dataset, the task number, its start scheduling time, and total duration are combined to calculate the start and end positions and span of the task scheduling interval. For example, if task T201 has a start scheduling time of 100ms and a total duration of 15ms, its scheduling interval is from 100ms to 115ms, with a span of 15ms. If task T202 has a start scheduling time of 105ms and a total duration of 20ms, its scheduling interval is from 105ms to 125ms, with a span of 20ms. By recording the time period position of each task, a structured task scheduling interval data table can be generated, recording the time occupancy of each task within the GPU scheduling window.

[0087] S313: Based on the task scheduling interval information, obtain the time range of the GPU scheduling window, determine the scheduling interval overlap time of each task, calculate the interval overlap ratio between two specified tasks, and filter the task combination with the interval overlap ratio greater than the scheduling overlap judgment benchmark value to obtain the overlapping dense task group.

[0088] Based on the task scheduling interval information, the system first determines the overall time range of the GPU scheduling window, for example, the scheduling window lasts from 100ms to 200ms. It then compares each task scheduling interval to determine if there is any overlap between two tasks. For example, if task T201's interval is 100ms to 115ms and T202's is 105ms to 125ms, the overlap time is 105ms to 115ms, with an overlap length of 10ms. The system calculates the overlap ratio between this overlap time and the scheduling time of the two tasks, taking the average of the two values. That is, the overlap ratio for T201 is 10 / 15 = 0.6667, and for T202 it is 10 / 20 = 0.5, with an average of 0.5833. If the scheduling overlap judgment benchmark is set to 0.5, then this task combination is identified as a densely overlapping task group. The above steps are repeated to perform cross-checking and overlap ratio statistics on all task combinations, filtering out all task groups that meet the overlap conditions to form a densely overlapping task set.

[0089] Please see Figure 5 The specific steps for obtaining a task set with a stable resource contention trend are as follows:

[0090] S411: Obtain the shared resource call data of each task in the overlapping dense task group, extract the shared memory access count, register call frequency and global storage access interval of the corresponding task, establish a resource type and access parameter correspondence structure according to task number, and generate a shared resource call frequency dataset.

[0091] After acquiring the overlapping and dense task groups, the system needs to extract the shared resource call data for each task. This data mainly includes three key indicators: shared memory access counts, register call frequency, and global storage access interval. First, this data is extracted through the task scheduling log or hardware access record module. For example, task T301 has 180 shared memory accesses, a register call frequency of 40 times per millisecond, and a global storage access interval of once every 12 milliseconds; task T302 has 200 accesses, a frequency of 45 times per millisecond, and an access interval of 10 milliseconds. Then, using the task number as an index, a data structure is constructed that corresponds to resource type and access parameters. Each resource type is treated as an independent field, and the task number is used as the primary key index, forming a dataset structure in the following format: T301 → {Memory: 180, Register: 40, Global Interval: 12}, T302 → {Memory: 200, Register: 45, Global Interval: 10}. In this way, the shared resource access characteristics of all tasks can be standardized and organized, uniformly constructing a complete shared resource call frequency dataset.

[0092] S412: Based on the shared resource access frequency dataset, with task number as the input order, the access frequency value of each type of shared resource is used as a variable dimension input to the local weighted regression algorithm to fit the change trajectory of resource access frequency in the task number sequence, obtain the access frequency fitting curve of each type of resource in the task distribution, and generate the trend of shared resource access frequency change.

[0093] After establishing a dataset of shared resource access frequencies, a locally weighted regression algorithm is needed to fit the trend of resource access frequency changes with task number. Specifically, this includes three types of indicators: shared memory access frequency, register access frequency, and global memory access interval. Locally weighted regression is a regression method that builds a weight model based on the local neighborhood of sample points. It is suitable for analyzing situations where resource access frequencies fluctuate but exhibit local patterns during task execution.

[0094] For each task number to be fitted, denoted as . The fitted access frequency value is expressed as:

[0095] ;

[0096] The parameters have the following meanings: Target task number The corresponding fitted value of shared resource access frequency (the unit depends on the resource type, such as access count, call count per millisecond, etc.); : The current task number to be fitted, for example, task T303. ; Task Number The corresponding actual resource access frequency, for example, the shared memory access count for T301 is 180; Task Number right The weighting coefficients reflect the task and The degree of relative proximity; : Total number of tasks, for example, if the current task number sequence is 301 to 305, then .

[0097] Weight of each sample point The weighting function is determined by the distance between its number and the target point number, and is defined as follows:

[0098] ;

[0099] in: : The sample task number, for example, T301 is 301; : The task number to be fitted; The smoothing coefficient (also known as bandwidth) controls the neighborhood range. A larger value indicates a wider range of tasks to be considered, while a smaller value only focuses on tasks with similar numbers. The larger the weight value, the closer the task number is to the target task, and the greater the influence of its resource usage data on the fitted value. In practical applications, samples with numbers closer to the target task indicate that their scheduling times are adjacent and their resource usage patterns are more likely to be similar; therefore, they should be given higher weights in the regression model. Conversely, the greater the difference in task numbers, the weaker the representativeness of its behavior, and the lower the weight will naturally be.

[0100] Taking shared memory access frequency as an example, a local weighted regression fitting calculation is performed, with the goal of calculating the frequency of shared memory access. The task is fitted and estimated. The known task number sequence is: 301, 302, 303, 304, 305, and the corresponding shared memory access counts are: 180, 200, 210, 205, 190 respectively. The smoothing parameter (bandwidth) is set to... .

[0101] The weighting function uses a Gaussian kernel and is calculated using the following formula:

[0102] ;

[0103] Enter the specific task number and bandwidth :

[0104] Task 301: Number difference is The square is 4:

[0105] ;

[0106] Task 302: Number difference is The square of 1:

[0107] ;

[0108] Task 303: Number difference is 0:

[0109] ;

[0110] Task 304: The difference in numbers is 1, and the square of the difference is 1.

[0111] ;

[0112] Task 305: The difference in numbers is 2, and the square is 4.

[0113] ;

[0114] Multiply the number of shared memory accesses for each task by its weight:

[0115] Task 301: ;

[0116] Task 302: ;

[0117] Task 303: ;

[0118] Task 304: ;

[0119] Task 305: ;

[0120] Calculate the weighted sum:

[0121] ;

[0122] Calculate the total weights:

[0123] ;

[0124] The formula for calculating the fitted value is:

[0125] ;

[0126] Therefore, the fitted value of the shared memory access frequency for task number 303 is 203.65, which can be used as an estimate of its access frequency trend in the current task sequence.

[0127] First, a Gaussian function is used to calculate the weight between each task and the target task number. The weight value is determined based on the difference in numbers; the closer the numbers are, the greater the weight, indicating a stronger influence of that task on the fitted value of the target task. Then, the access frequency of each task is multiplied by its corresponding weight, and the results are summed to obtain a weighted sum. Simultaneously, all weight values ​​are summed to obtain a total weight. Finally, the weighted sum is divided by the total weight to obtain the fitted value of the current task's access frequency. This fitted value represents the estimated level of that task under the shared resource usage trend in the overall task sequence. The entire process effectively smooths out local abnormal fluctuations and reflects the changing patterns of resource access.

[0128] S413: Based on the trend of shared resource access frequency, determine the first derivative of the fitted curve in the interval of all task numbers, and filter the task number group whose absolute value of the first derivative is lower than the benchmark value for judging resource access changes to obtain the set of tasks with stable resource contention trends.

[0129] After fitting the trend of shared resource access frequency changes, the system needs to perform first derivative analysis on each fitted curve within the task number interval to identify whether the resource access changes are stable. In practice, the task number is used as the independent variable and the fitted value is used as the dependent variable. The first derivative is used to approximate the estimation by the difference between the fitted frequency values ​​of adjacent tasks and the difference in the number. For example, the fitted frequencies of tasks T401 to T405 are 200, 203, 204, 202, and 201, respectively, corresponding to the numbers 401 to 405. The derivative between T401 and T402 is (203-200) / (402-401)=3, between T402 and T403 it is (204-203) / (403-402)=1, between T403 and T404 it is (202-204) / (404-403)=-2, and between T404 and T405 it is (201-202) / (405-404)=-1. Then, the absolute value of the derivative of each segment is used for filtering. If the benchmark value for judging resource access changes is set to 2, then all intervals with absolute values ​​less than 2 are retained, and task numbers exceeding the benchmark value are removed. In this example, only the absolute value of the derivative of the interval from T401 to T402 is 3, exceeding the benchmark. The values ​​of the remaining segments are 1, 2, and 1, respectively. Among them, 1 and 2 satisfy the boundary conditions, so only the tasks corresponding to the numbers T403 to T405 are retained, thus forming a set of tasks with stable resource contention trends. Through this process, tasks with slow changes and stable usage behavior in resource access trends can be effectively identified.

[0130] Please see Figure 6 The specific steps for obtaining the dynamic allocation list of GPU task resources are as follows:

[0131] S511: Obtain the address access frequency record data of the task set with stable resource contention trend and the GPU scheduling cycle, extract the scheduling sequence number of each task and the dwell time of the task instruction migration path segment, establish the correspondence between task number, path segment dwell time and scheduling sequence, and generate a set of task resource access related parameters.

[0132] After identifying a set of tasks with stable resource contention trends, the system needs to extract associated parameters for each task by combining the address access frequency records within the GPU scheduling cycle. The specific process includes three key data points: the task's scheduling sequence number, path segment dwell time, and its address access frequency distribution. First, the task's sequential position in the scheduling sequence is extracted from the scheduling log. For example, task T501 is scheduled as the 3rd task within the cycle, and T502 is the 5th. Then, the path segment dwell time information is combined; for example, the total dwell time of all path segments for T501 is 18 milliseconds, and for T502 it is 22 milliseconds. Finally, the corresponding address access records for the task are matched, and its access frequency is recorded for subsequent mapping evaluation. By integrating the task number, dwell time, and scheduling sequence number, a mapping relationship structure is established between the three, for example: T501 → {Sequence 3, Dwell Time 18}, T502 → {Sequence 5, Dwell Time 22}, to form a set of task resource access associated parameters.

[0133] S512: Based on the task resource access associated parameter set, filter the address segments with the lowest access frequency value in all records as candidate mapping targets, sort them from largest to smallest according to the dwell time of the path segment corresponding to the task, and generate a task address priority allocation structure table.

[0134] After constructing the task resource access association parameter set, the system needs to combine GPU address access frequency data to identify the address segments with the lowest frequency values ​​among all records. These segments indicate that they are accessed the least during the scheduling cycle, have a low probability of resource conflicts, and are therefore suitable for priority allocation. For example, in a certain GPU scheduling cycle, the address segments with the lowest access frequency are between numbers 1200 and 1300. Next, the system sorts the task list from largest to smallest by the task path segment residence time. For example, if T502 has a residence time of 22 milliseconds and T501 has a residence time of 18 milliseconds, the sorted order is T502, T501, forming a task address priority allocation structure table, that is, the longer the residence time, the higher the priority is given to matching address segments with higher idle time.

[0135] S513: Based on the task address priority allocation structure table, bind the corresponding address segment start number to each task number in sequence to obtain the GPU task resource dynamic allocation list;

[0136] Based on the task address priority allocation structure table, the system allocates address resources to tasks one by one according to their order, binding them sequentially to the corresponding low-access-frequency address segment numbers. For example, if the current candidate address segment range is 1200 to 1300, and it is segmented into blocks of 10 units, then the first task T502 is bound to an address segment starting number of 1200, the second task T501 is bound to an address segment starting number of 1210, and so on, ensuring that the allocated segments do not overlap. The longer a task resides, the earlier its bound address segment appears, thereby reducing the probability of address access conflicts for highly resident tasks. The system generates a complete dynamic allocation list of GPU task resources, which includes the mapping relationship between task numbers and the starting numbers of their allocated address segments, such as T502→1200, T501→1210. This list can be directly used in the instruction execution phase of the GPU resource scheduling module to achieve on-demand resource binding and dynamic reuse.

[0137] The GPU server resource dynamic allocation management device is used to execute the GPU server resource dynamic allocation management method. The GPU server resource dynamic allocation management device includes:

[0138] The path extraction and segmentation module obtains the instruction scheduling records of all tasks within the GPU scheduling cycle, extracts the jump path sequence of each instruction from one position to the next position, and divides the task instruction migration path segments.

[0139] The migration path duplication identification module pairs and combines task instruction migration path segments with the same thread number, and uses the longest common subsequence algorithm to determine the degree of duplication of migration behavior between tasks, marking the set of tasks with duplicate migration paths;

[0140] The scheduling interval overlap analysis module obtains the scheduling time of each duplicate migration path task set and the total dwell time of all task instruction migration path segments to calculate the scheduling interval occupied by the task. It then compares this interval with the time range of the GPU scheduling window to filter out densely overlapping task groups.

[0141] The resource access trend assessment module obtains the frequency of shared resource calls for each task in the overlapping and dense task group, judges the trend of shared resource access frequency changes among tasks, identifies task combinations with stable trends, and obtains a set of tasks with stable resource contention trends.

[0142] The address resource dynamic allocation module associates the task set with stable resource contention trends with the address access frequency record within the GPU scheduling cycle, determines the allocation correspondence between task number and corresponding address segment, and obtains the GPU task resource dynamic allocation list.

[0143] A computer device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the GPU server resource dynamic allocation management device as described above.

[0144] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the GPU server resource dynamic allocation and management method described above.

[0145] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for dynamic allocation and management of GPU server resources, characterized in that, Includes the following steps: S1: Obtain the instruction scheduling records of all tasks within the GPU scheduling cycle, extract the jump path sequence of each instruction from one position to the next position, and divide the task instruction migration path segments. S2: Pair up and combine the task instruction migration path segments with the same thread number, determine the degree of duplication of migration behavior between tasks using the longest common subsequence algorithm, and mark the set of tasks with duplicate migration paths; S3: Obtain the scheduling time of each repeated migration path task set and the total dwell time of all task instruction migration path segments to calculate the scheduling occupancy interval of the task, compare it with the time range of the GPU scheduling window, and filter overlapping and dense task groups. S4: Obtain the frequency of shared resource calls for each task in the overlapping and dense task group, determine the trend of shared resource access frequency changes among tasks, identify task combinations with stable trends, and obtain a set of tasks with stable resource contention trends. S5: Associate the resource contention trend stable task set with the address access frequency record within the GPU scheduling cycle, determine the allocation correspondence between task number and corresponding address segment, and obtain the GPU task resource dynamic allocation list.

2. The GPU server resource dynamic allocation and management method according to claim 1, characterized in that, The task instruction migration path segment includes the jump path segment number, instruction jump order position, and single segment dwell time. The repeated migration path task set includes the task corresponding path segment sequence, path segment repetition value, and task pairing group identifier. The overlapping dense task group includes the task scheduling time period, GPU scheduling window position mapping value, and inter-task interval overlap ratio. The resource contention trend stable task set includes shared memory call change trend category, register call change trend category, and global storage access change trend category. The GPU task resource dynamic allocation list includes the task number and address segment mapping relationship, address access frequency sorting result, and address allocation order index.

3. The GPU server resource dynamic allocation and management method according to claim 1, characterized in that, The specific steps for obtaining the task instruction migration path segment are as follows: S111: Obtain the instruction scheduling records of all tasks within the GPU scheduling cycle, call the execution start position number, jump target position number and scheduling time corresponding to each instruction, organize adjacent jump paths in the order of scheduling time, and obtain the internal jump path sequence of the task. S112: Based on the internal jump path sequence of the task, the segment boundary is determined according to the execution interval time between paths and the average dwell time within the task, and the jump path is divided to obtain the jump path division interval. S113: Divide the interval according to the jump path, mark the segment number order, path number range and dwell time of each segment, and associate with the original task number information to obtain the task instruction migration path segment.

4. The GPU server resource dynamic allocation and management method according to claim 3, characterized in that, The specific steps for obtaining the set of repeated migration path tasks are as follows: S211: Obtain the task instruction migration path segment, classify it according to the thread number to which the task belongs, extract all tasks under the same thread number as combination candidates, pair up the task numbers of each pair of candidate tasks, and generate a task pairing sequence group within the thread. S212: Extract the task pairing sequence group within the thread, extract the migration path segment number sequence of each pair of tasks, call the longest common subsequence algorithm, compare the path segment number order in the sequence bit by bit, obtain the length of the longest common subsequence of the path segment numbers, and use the ratio between the shorter of the two as the basis for judging the degree of repetition, and obtain the path segment repetition analysis result. S213: Based on the path segment duplication analysis results, filter the task pairings with ratios exceeding the path segment duplication judgment benchmark value, identify the task set with close path segment duplication relationships, and obtain the duplicate migration path task set.

5. The GPU server resource dynamic allocation and management method according to claim 4, characterized in that, The specific steps for obtaining the overlapping dense task group are as follows: S311: Obtain the scheduling time record of each task in the repeated migration path task set, extract the starting scheduling time of the task, call the dwell time of all path segments in the corresponding task instruction migration path segment data, calculate the total execution time of each task, and generate a task scheduling time dataset. S312: Based on the task scheduling duration dataset, combine the start scheduling time and total task duration according to the task number, record the start and end positions and interval span of the time period for each task, and generate the task scheduling occupied interval. S313: Based on the task scheduling occupancy interval information, obtain the time range of the GPU scheduling window, determine the scheduling interval overlap time period of each task, calculate the interval overlap ratio between two specified tasks, and filter the task combination with the interval overlap ratio greater than the scheduling overlap judgment benchmark value to obtain the overlapping dense task group.

6. The GPU server resource dynamic allocation and management method according to claim 5, characterized in that, The specific steps for obtaining the task set with a stable resource contention trend are as follows: S411: Obtain the shared resource call data of each task in the overlapping dense task group, extract the shared memory access count, register call frequency and global storage access interval of the corresponding task, establish a resource type and access parameter correspondence structure according to the task number, and generate a shared resource call frequency dataset. S412: Based on the shared resource call frequency dataset, with task number as the input order, the access frequency value of each type of shared resource is used as a variable dimension to input into the local weighted regression algorithm to fit the change trajectory of resource access frequency in the task number sequence, obtain the access frequency fitting curve of each type of resource in the task distribution, and generate the trend of shared resource access frequency change. S413: Based on the trend of shared resource access frequency change, determine the first derivative of the fitted curve in the interval of all task numbers, and filter the task number group whose absolute value of the first derivative is lower than the benchmark value for judging resource access changes to obtain a set of tasks with stable resource contention trends.

7. The GPU server resource dynamic allocation and management method according to claim 6, characterized in that, The specific steps for obtaining the dynamic allocation list of GPU task resources are as follows: S511: Obtain the resource contention trend stable task set and address access frequency record data within the GPU scheduling cycle, extract the scheduling sequence number of each task and the dwell time of the task instruction migration path segment, establish the correspondence between task number, path segment dwell time and scheduling sequence, and generate a task resource access association parameter set. S512: Based on the task resource access association parameter set, filter the address segments with the lowest access frequency value in all records as candidate mapping targets, sort them from largest to smallest according to the dwell time of the path segment corresponding to the task, and generate a task address priority allocation structure table. S513: Based on the task address priority allocation structure table, bind the corresponding address segment start number to each task number in sequence to obtain the GPU task resource dynamic allocation list.

8. A GPU server resource dynamic allocation and management device, characterized in that, The GPU server resource dynamic allocation management device is used to execute the GPU server resource dynamic allocation management method according to any one of claims 1 to 7, and the GPU server resource dynamic allocation management device includes: The path extraction and segmentation module obtains the instruction scheduling records of all tasks within the GPU scheduling cycle, extracts the jump path sequence of each instruction from one position to the next position, and divides the task instruction migration path segments. The migration path duplication identification module pairs and combines the migration path segments of the task instructions with the same thread number, and uses the longest common subsequence algorithm to determine the degree of duplication of migration behavior between tasks, and marks the set of tasks with duplicate migration paths. The scheduling interval overlap analysis module obtains the scheduling time of each repeated migration path task set and the total dwell time of all task instruction migration path segments to calculate the scheduling occupancy interval of the task, compares it with the time range of the GPU scheduling window, and filters out overlapping and densely overlapping task groups. The resource access trend assessment module obtains the frequency of shared resource calls for each task in the overlapping and dense task group, determines the trend of shared resource access frequency changes among tasks, identifies task combinations with stable trends, and obtains a set of tasks with stable resource contention trends. The address resource dynamic allocation module associates the resource contention trend stable task set with the address access frequency record within the GPU scheduling cycle, determines the allocation correspondence between task number and corresponding address segment, and obtains the GPU task resource dynamic allocation list.

9. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, and when the processor executes the computer program, it implements the GPU server resource dynamic allocation management device as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the GPU server resource dynamic allocation and management method according to any one of claims 1 to 7.

Images