GPU (Graphics Processing Unit) server resource dynamic allocation management method and device, equipment and medium

Abstract

The invention relates to the technical field of computing resource scheduling, in particular to a GPU server resource dynamic allocation management method, device and equipment and a medium, the GPU server resource dynamic allocation management method comprises the steps of extracting a jump path to divide task migration segments, matching path repeated tasks in a thread, screening overlapped tasks in combination with scheduling and residence time, and performing dynamic allocation management on GPU server resources. And analyzing a resource access trend to identify scrambling stable combinations, and associating address frequencies to generate a dynamic allocation list. According to the method, the behavior similarity among multiple tasks is identified by extracting the jump path among the tasks and performing repetition analysis, the dense overlapping interval of task execution is accurately delimited by means of cross mapping of task scheduling time and path residence time, and the task performance of the multiple tasks is determined in combination with the derivative judgment mode of the change trend of the access frequency of the shared resources. And identifying a task combination with stable resource scrambling behavior distribution, and establishing a dynamic binding strategy between the task and the GPU address resource based on the joint sorting of the address access frequency and the residence duration.

Description

Technical Field

[0001] The present invention relates to the technical field of computing resource scheduling, and in particular to a method, device, equipment and medium for dynamic allocation management of GPU server resources. Background Art

[0002] The field of computing resource scheduling technology involves the allocation and management of various hardware resources in the 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 management method of GPU server resources refers to allocating GPU computing resources through predefined quota static division and other methods in a server environment where multiple users share graphics processor resources to achieve resource control and scheduling, so as to solve the problem of lack of dynamic response mechanism for resource allocation when GPU servers face concurrent access by multiple tasks and multiple users.

[0004] Existing technologies manage resources by statically allocating quotas, but lack the ability to capture dynamic changes in task behavior. In multi-user concurrent access scenarios, resource allocation often relies on predefined strategies and fails to make real-time adjustments based on differences in execution paths between tasks and resource contention. This leads to structural vacancies in resource utilization and can easily cause some tasks to have insufficient resources within the scheduling window. For example, even if Task A and Task B have overlapping scheduling times but different access resources, they are still included in the same quota limit, resulting in reduced task execution efficiency. At the same time, when resource-intensive tasks are concentrated, the lack of analysis methods for behavioral similarity and access trends makes it impossible to effectively judge resource allocation priorities, resulting in the phenomenon of hot address segments being frequently competed for by multiple tasks, affecting overall GPU performance. Summary of the Invention

[0005] The purpose of the present invention is to solve the shortcomings of the prior art and to propose a method, device, equipment and medium for dynamic allocation management of GPU server resources.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a method for dynamically allocating and managing 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, and divide the task instruction migration path segments;

[0008] S2: Pair and combine the task instruction migration path segments with the same thread number, determine the degree of repetition of migration behaviors between tasks using the longest common subsequence algorithm, and mark the repeated migration path task sets;

[0009] S3: Obtain the scheduling time of each repeated migration path task set and the sum of the residence time of all task instruction migration path segments to calculate the task scheduling occupancy interval, compare it with the time range of the GPU scheduling window, and filter out overlapping dense task groups;

[0010] S4: Obtain the shared resource call frequency of each task in the overlapping dense task group, determine the changing trend of shared resource access frequency among tasks, identify the task combination with a stable changing trend, and obtain the task set with a stable resource contention trend;

[0011] S5: Associating the resource contention trend stable task set with the address access frequency record in the GPU scheduling cycle, determining the allocation correspondence between the task number and the corresponding address segment, and obtaining a GPU task resource dynamic allocation list.

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

[0013] As a further solution of the present invention, the step of obtaining the task instruction migration path segment is specifically as follows:

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

[0015] S112: Based on the jump path sequence within the task, segment boundaries are determined according to the execution interval between paths and the average residence time within the task, and jump paths are divided to obtain jump path division intervals;

[0016] S113: Divide the jump path into sections, mark the segment number sequence, path number range and residence time of each segment, and associate with the original task number information to obtain the task instruction migration path segment.

[0017] As a further solution of the present invention, the step of obtaining the repeated migration path task set is specifically as follows:

[0018] S211: Obtain the task instruction migration path segments, classify them according to the thread numbers to which they belong, extract all tasks under the same thread number as combination candidates, pair the task numbers of each candidate task in each group, and generate an intra-thread task pairing sequence group;

[0019] S212: Extracting the task pairing sequence group within the thread, extracting the migration path segment number sequence of each pair of tasks, calling the longest common subsequence algorithm, performing a bit-by-bit comparison on the order of the path segment numbers in the sequence, obtaining the ratio of the longest common subsequence length of the path segment numbers to the shorter total number of path segment numbers, and using the ratio as a basis for determining the degree of duplication, thereby obtaining a path segment duplication analysis result;

[0020] S213: According to the path segment duplication analysis result, the task pairing relationships whose ratios exceed the path segment duplication judgment reference value are screened, and a task set with close path segment duplication relationships is identified to obtain a repeated migration path task set.

[0021] As a further solution of the present invention, the step of obtaining the overlapping dense task group is specifically as follows:

[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, and call the residence time of all path segments in the corresponding task instruction migration path segment data, calculate the total task execution time of each task, and generate a task scheduling time data set;

[0023] S312: Based on the task scheduling duration data set, combine the start scheduling time and the total task duration according to the task number, record the start and end positions and interval span of each task time period, and generate the task scheduling occupancy interval;

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

[0025] As a further solution of the present invention, the steps for obtaining the task set with a stable resource contention trend are specifically as follows:

[0026] S411: Acquire shared resource call data of each task in the overlapping dense task group, extract the number of shared memory accesses, register call frequency, and global storage access interval of the corresponding task, establish a corresponding structure between resource type and access parameter according to the task number, and generate a shared resource call frequency data set;

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

[0028] S413: According to the change trend of the shared resource access frequency, determine the first-order derivative of the fitting curve in all task number intervals, select the task number group whose absolute value of the first-order derivative is lower than the resource access change judgment benchmark value, and obtain the task set with a stable resource contention trend.

[0029] As a further solution of the present invention, the steps of obtaining the GPU task resource dynamic allocation list are specifically as follows:

[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 residence time of the task instruction migration path segment, establish a correspondence between the task number, the path segment residence time and the scheduling sequence, and generate a task resource access association parameter set;

[0031] S512: Based on the task resource access associated parameter set, select the address segments in the address access frequency records whose access frequency values ​​are in the lowest range among all records as candidate mapping targets, sort the path segments corresponding to the tasks from largest to smallest residence time, and generate a task address priority allocation structure table;

[0032] S513: Based on the task address priority allocation structure table, bind each task number to the corresponding address segment starting number in sequence to obtain a 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, and 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, and divides the task instruction migration path into segments;

[0035] A migration path duplication identification module pairs and combines the task instruction migration path segments of the same thread number, determines the duplication degree of migration behaviors between tasks through the longest common subsequence algorithm, and marks the repeated migration path task set;

[0036] The scheduling interval overlap analysis module obtains the scheduling time of each repeated migration path task set and the sum of the residence 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 the overlapping dense task group;

[0037] A resource access trend assessment module obtains the shared resource call frequency of each task in the overlapping intensive task group, determines the changing trend of the shared resource access frequency among tasks, identifies the task combination with a stable changing trend, and obtains a task set with a stable resource contention trend;

[0038] The address resource dynamic allocation module associates the resource contention trend stable task set with the address access frequency record in the GPU scheduling cycle, determines the allocation correspondence between the task number and the 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 implements the GPU server resource dynamic allocation management device as described above when executing the computer program.

[0040] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method for dynamically allocating and managing GPU server resources as described above.

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

[0042] In the present invention, by extracting the jump paths between tasks and performing repetitive analysis, the behavioral similarities between multiple tasks are identified. With the help of cross-mapping of task scheduling time and path residence time, the dense overlapping intervals of task execution are accurately delineated. Combined with the derivative judgment method of the change trend of shared resource access frequency, the task combination with a stable distribution of resource contention behavior is identified. Based on the joint sorting of address access frequency and residence time, a dynamic binding strategy between tasks and GPU address resources is established to achieve optimized allocation of high-frequency access addresses, effectively alleviate the resource competition bottleneck in concurrent task scheduling, improve resource utilization efficiency and scheduling accuracy, avoid address space conflicts and resource redundancy waste caused by static allocation, and enhance the response stability and scheduling flexibility of GPU servers when facing high-concurrency tasks. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0045] Figure 3This is a detailed flow chart of S2 of the present invention;

[0046] Figure 4 This is a detailed flow chart of S3 of the present invention;

[0047] Figure 5 This is a detailed flow chart of S4 of the present invention;

[0048] Figure 6 This is a detailed flow chart of S5 of the present invention. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present 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 only used to explain the present invention and are not intended to limit the present invention.

[0050] See also Figure 1 The present invention provides a technical solution: a method for dynamically allocating and managing 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, and divide the task instruction migration path segments;

[0052] S2: Pair and combine the task instruction migration path segments with the same thread number, determine the degree of repetition of migration behaviors between tasks using the longest common subsequence algorithm, and mark the repeated migration path task sets;

[0053] S3: Obtain the scheduling time of each repeated migration path task set and the sum of the residence time of all task instruction migration path segments to calculate the task scheduling occupancy interval, compare it with the time range of the GPU scheduling window, and filter out overlapping dense task groups;

[0054] S4: Obtain the shared resource call frequency of each task in the overlapping dense task group, determine the changing trend of shared resource access frequency among tasks, identify the task combination with a stable changing trend, and obtain the task set with a stable resource contention trend;

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

[0056] The task instruction migration path segment includes the jump path segment number, instruction jump sequence position, and single-segment residence 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 task interval overlap ratio. The resource contention trend stable task set includes the 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 mapping relationship between task number and address segment, address access frequency sorting result, and address allocation sequence index.

[0057] See also Figure 2 ,The steps for obtaining the task instruction migration path segment are as follows:

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

[0059] To obtain the instruction scheduling records for all tasks within a GPU scheduling cycle, you first need to call the GPU task scheduling log module to extract the instruction scheduling information of each GPU task, including the instruction number, execution start position number, jump target position number, and scheduling time. When structuring this information, it should be converted into a structure array in a unified format. Each structure contains four fields and is sorted in ascending order of scheduling time. The sorting operation can be completed using bubble sort or quick sort. After sorting, the jump paths of two adjacent instructions are spliced ​​and organized to form the path sequence of the task. For example, the instruction records of a task in a certain scheduling cycle are: instruction 1 (starting position 10, target position 20, scheduling time 10ms), instruction 2 (starting position 20, target position 35, scheduling time 15ms), instruction 3 (starting position 35, target position 60, scheduling time 20ms). After sorting, the resulting path sequence is [10→20→35→60]. This path sequence is the jump path sequence of the task within the GPU scheduling cycle.

[0060] S112: Based on the jump path sequence within the task, segment boundaries are determined according to the execution interval between paths and the average residence time within the task, and jump paths are divided to obtain jump path division intervals;

[0061] Based on the jump path sequence within the task, it is necessary to first extract the execution interval time between the paths, that is, calculate the difference in scheduling time corresponding to 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. At the same time, the average residence time within the task needs to be calculated. The residence time can be calculated by summing the time differences between the target position and the next starting position of the instructions in all jump paths and then dividing it by the number of jump segments. If there are three path segments with time differences of 3ms, 4ms, and 5ms respectively, the average residence time is (3+4 +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, the threshold is 6ms), 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 one example, the intervals between paths are 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 jump path into sections, mark the segment number sequence, path number range, and residence time of each segment, and associate it with the original task number information to obtain the task instruction migration path segment;

[0063] Divide the intervals according to the jump path, and mark the segment numbers in each segment in sequence. For example, the first segment is segment 1, the second segment is segment 2, and so on. The path number range of each segment is recorded. For example, segment 1 includes path numbers 1 to 3, segment 2 only contains path 4, and segment 3 is path 5. At the same time, the residence time within each segment is counted. The residence time of all jumps in each segment path can be summed. For example, the residence time of segment 1 is 3ms+4ms=7ms, segment 2 is 2ms, and segment 3 is 6ms. Then, these segment information are bound to the original task number. For example, if the task number is T005, the output is: T005-segment 1 (path 1-3, residence time 7ms), T005-segment 2 (path 4, residence time 2ms), T005-segment 3 (path 5, residence time 6ms). Through this structured data, the migration path segment information of the task can be fully represented.

[0064] See also Figure 3 The specific steps for obtaining the repeated migration path task set are as follows:

[0065] S211: Obtain task instruction migration path segments, classify tasks by thread numbers, extract all tasks under the same thread number as combination candidates, pair task numbers in each group of candidate tasks, and generate intra-thread task pairing sequence groups;

[0066] After obtaining the task instruction migration path segment, it is necessary to perform classification operations based on the thread number of each task. First, the task number corresponding to each migration path segment is extracted and mapped to the thread number to which it belongs. For example, among 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 set of candidate tasks {T001, T003, and T004}, and thread B can be organized into another set of candidate tasks {T002, T005}. Then, the task number pairing operation is performed on each set of candidate tasks. If there are 3 tasks under thread A, C(3, 2) = 3 pairs can be formed: {(T001, T003, T004}, {(T002, T005}, {(T001, T003, T004}, {(T002, T005}, {(T002, T005}, {(T001, T003, T004}, {(T002, T005}, {(T002, T005}, {(T001, T003, T004}, {(T002, T005} 001, T004), (T003, T004)}, and the pairing under thread B is {(T002, T005)}. The pairing results under all threads are output as intra-thread task pairing sequence groups. For example, the pairing sequence group of thread A is S_A={(T001, T003), (T001, T004), (T003, T004)}, and the pairing sequence group of thread B is S_B={(T002, T005)}. The entire step process requires the use of a structured mapping table to record the task number, thread number, and corresponding path segment sequence. The candidate tasks are traversed through nested loops and pairing relationships are formed to ensure that there is no duplication between pairing groups and that the thread ownership is consistent, thus forming the basic data for task migration path segment comparison.

[0067] S212: Extracting task pairing sequence groups within the thread, extracting the migration path segment number sequence of each pair of tasks, calling the longest common subsequence algorithm, performing a bit-by-bit comparison on the order of the path segment numbers in the sequence, obtaining the ratio of the longest common subsequence length of the path segment numbers to the shorter total number of path segment numbers, and using the ratio as a basis for determining the degree of duplication, thereby obtaining a path segment duplication analysis result;

[0068] After obtaining the task pairing sequence within a thread, the migration path segment numbering sequences within each pair of tasks need to be analyzed for similarity. During execution, the complete migration path segment numbering sequence is first extracted from each task. For example, if the path segment numbering sequence corresponding to task T101 is [1, 3, 4, 5, 7], and the path segment numbering sequence corresponding to task T102 is [2, 3, 4, 6, 7], then these two tasks are considered a pair for comparison and analysis. Next, the longest common subsequence algorithm is invoked to perform a bit-by-bit comparison of the two path segment numbering sequences.

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

[0070] ;

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

[0072] In order to more accurately identify the structural consistency of repeated behaviors in path segment sequences, the position weight adjustment parameter is introduced. , used to weight the degree of deviation in the position of path segments in the sequence. This parameter makes the contribution of common path segments closer in sequence greater, the more obvious the position deviation is, and the smaller the ratio is. The ratio calculation formula is as follows:

[0073] ;

[0074] in, : The adjusted path segment repetition ratio, ranging from [0, 1], is used to determine the degree of repetition between tasks; : Same as above, it represents the length of the shorter path segment sequence in the two tasks involved in the comparison; : The longest common subsequence length; : The first segment in the public path The index position of the item in the sequence of path segments for task 1 (counted from 1); : The first segment in the public path The index position of the item in the sequence of path segments of task 2; : The deviation value of the index position of the common path segment in the two tasks; : Position difference adjustment coefficient. The setting basis of the position difference adjustment coefficient is mainly based on the actual impact of the consistency of the position of the path segment in different tasks on the judgment of structural repetition. In the GPU task scheduling process, if the relative position difference of the same path segment in two tasks is small, it usually means that their execution processes have a high degree of structural consistency, so it is necessary to give it a higher repetition weight; on the contrary, if the position of the same path segment in different tasks is far apart, even if the content is the same, there are obvious differences in the structure of its scheduling path, and its contribution to the overall repetition ratio needs to be reduced. In order to achieve this adjustment goal, the position difference adjustment coefficient is introduced, and the recommended setting range is 0.2 to 0.5. When the value is 0.2, it means that a larger path segment position offset is allowed, and the tolerance for structural differences is high, which is suitable for scenarios with loose thread scheduling; when the value is 0.5, a higher repetition score is only allowed when the path segment positions are close, which is suitable for applications with high requirements for strict structural alignment. In actual tests, it was found that when the average length of task path segments is between 5 and 8, setting it to 0.3 can effectively distinguish between the repeated continuous paths and the overlapped scattered paths. Therefore, it can be used as a general recommended value and is suitable for most GPU instruction migration structure analysis tasks.

[0075] Assume that task T101 = [1, 3, 4, 5, 7], task T102 = [2, 3, 4, 6, 7], the longest common subsequence is [3, 4, 7], the corresponding index positions are: 2nd, 3rd, 5th in T101; 2nd, 3rd, 5th in T102, so ,set up , substitute into the formula to calculate:

[0076] ;

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

[0078] ;

[0079] First, the path segment number sequences of each task pair are extracted. The longest common subsequence algorithm is used to calculate the length of the common segment sequence between the two tasks. This length is then compared with the length of the task with fewer path segments to determine the baseline degree of repetition. To further account for the positional offset of path segments within the sequence, a position weight adjustment parameter is introduced. Each matching path segment is weighted by its positional difference to obtain a repetition ratio, ranging from 0 to 1, with larger values ​​indicating stronger repetition. For example, the ratio of tasks T101 and T102 is 0.6, indicating relatively consistent structures; the ratio of tasks T102 and T103 is 0.48125, indicating some overlap but weak consistency. The baseline value for repetition determination is set at 0.6. This is based on the observation in actual GPU task scheduling path statistics that when two tasks have five path segments each and three of them have identical content and order, the calculated ratio is 0.6. This structure typically exhibits continuous migration regions and shared execution flows in the scheduling graph, making it representative. Task pairs with a ratio below 0.6 exhibit scattered path overlaps, significant positional offset, and insufficient structural similarity. Therefore, taking 0.6 as the repetition judgment benchmark value can effectively distinguish the task sets with close path repetition.

[0080] S213: Based on the path segment duplication analysis results, screen task pairing relationships whose ratios exceed a path segment duplication judgment benchmark value, identify task sets with close path segment duplication relationships, and obtain a repeated migration path task set;

[0081] After completing the path segment duplication analysis, the system will uniformly filter the repetition ratios of task pairs in all threads. First, set the benchmark value for path segment duplication judgment, for example, set it to 0.6, traverse all task pairing records, extract the pairing entries with a ratio higher than the benchmark value, and record the corresponding task numbers. For example, if the repetition ratio of (T101, T102) is 0.6, it will be retained if it meets the conditions. If the ratio of (T102, T103) is 0.48125, it does not meet the screening conditions and is eliminated. Then, according to the retention criteria, the task pairing entries are selected. The pairing relationships retained are clustered or merged to sort out a group of task sets with close repetitive path segments. For example, if (T101, T102), (T102, T104), and (T101, T104) all meet the ratio condition, then the three can be merged into a task set {T101, T102, T104}. Each set is a set of repeated migration path task sets. This process can be achieved by structured merging through the union-find set or graph connected component algorithm, and all task set results that meet structural consistency are output.

[0082] See also Figure 4 ,The specific steps for obtaining overlapping dense task groups are:

[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, and call the residence time of all path segments in the corresponding task instruction migration path segment data to calculate the total task execution time of each task, and generate a task scheduling time data set;

[0084] After obtaining the repeated migration path task set, it is necessary to organize the scheduling time records of each task in it. First, extract the starting scheduling time of each task from the task scheduling log. For example, the starting 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, extract the residence time of each path segment. The residence time can be the cumulative value of the time each instruction stays in the path segment. For example, the residence times of the five path segments of T201 are 3ms, 4ms, 2ms, 5ms, and 1ms respectively, so the total task duration is 3+4+2+5+1=15ms. Similarly, if the total residence time of the path segments of T202 is 20ms, the total task execution duration is 20ms. In this way, the starting scheduling time of each task and the cumulative residence time of the path segments are statistically integrated to form a complete task scheduling duration dataset. Each record contains the task number, starting scheduling time, and total task execution duration.

[0085] S312: Based on the task scheduling duration data set, the start scheduling time and the total task duration are combined according to the task number, and the start and end positions and interval span of each task time period are recorded to generate the task scheduling occupancy interval;

[0086] Based on the task scheduling duration dataset, the number of each task is combined with its starting scheduling time and total duration to calculate the start and end positions and span length of the task scheduling interval. For example, if the starting scheduling time of task T201 is 100ms and the total task duration is 15ms, then its scheduling interval is 100ms to 115ms, with an interval span of 15ms; if the starting scheduling time of task T202 is 105ms and the total duration is 20ms, then its scheduling interval is 105ms to 125ms, with an interval span of 20ms; in this process, by recording the time period position of each task, a structured task scheduling occupancy interval data table can be generated to record the time occupancy of each task in the GPU scheduling window.

[0087] S313: Based on the task scheduling occupation interval information, the time range of the GPU scheduling window is obtained, the scheduling interval overlap time period of each task is determined, the interval overlap ratio between two specified tasks is calculated, and the task combinations whose interval overlap ratio is greater than the scheduling overlap judgment reference value are selected to obtain a densely overlapping task group;

[0088] Based on the task scheduling occupancy 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. The task scheduling intervals are compared item by item to determine whether there is interval overlap between the two tasks. For example, the interval of task T201 is 100ms to 115ms, and that of T202 is 105ms to 125ms. The intersection time period between the two is 105ms to 115ms, and the overlapping interval length is 10ms. The overlap ratio of the intersection time period and the scheduling time of the two tasks is calculated, and the average value between the two is taken. That is, the overlap ratio of T201 is 10 / 15=0.6667, and that of T202 is 10 / 20=0.5, with an average value of 0.5833. If the scheduling overlap judgment benchmark value is set to 0.5, the task combination is identified as a scheduling overlap-intensive task group. Repeat the above steps, perform cross-detection and overlap ratio statistics on all task combinations, and screen out all task groups that meet the overlap conditions to form an overlapping-intensive task set.

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

[0090] S411: Acquire shared resource call data of each task in the overlapping dense task group, extract the number of shared memory accesses, register call frequency, and global storage access interval of the corresponding task, establish a corresponding structure between resource type and access parameter according to the task number, and generate a shared resource call frequency data set;

[0091] After obtaining a group of overlapping, densely packed tasks, the system needs to extract shared resource call data for each task. This data primarily includes three key metrics: shared memory access count, register call frequency, and global memory access interval. First, extract this data using the task scheduling log or hardware access recording module. For example, task T301 has 180 shared memory accesses, a register call frequency of 40 per millisecond, and a global memory access interval of 12 milliseconds. Task T302 has 200 accesses, a frequency of 45 per millisecond, and an access interval of 10 milliseconds. Subsequently, using the task number as an index, a data structure is constructed that maps resource types to access parameters. Each resource type is treated as an independent field, and the task number is used as the primary key index. This results in a dataset structured as follows: T301 → {Memory: 180, Register: 40, Global Interval: 12}, T302 → {Memory: 200, Register: 45, Global Interval: 10}. This approach standardizes the shared resource access characteristics of all tasks, constructing a comprehensive shared resource call frequency dataset.

[0092] S412: Based on the shared resource call frequency dataset, with the task number as the input order, the access frequency value of each type of shared resource is input as the variable dimension into the local weighted regression algorithm, fitting the change trajectory of the resource access frequency in the task number sequence, obtaining the access frequency fitting curve of each type of resource in the task distribution, and generating the shared resource access frequency change trend;

[0093] After establishing a shared resource call frequency dataset, a local weighted regression algorithm is used to fit the trend of resource access frequency as it changes with task number. Specifically, this algorithm includes three metrics: shared memory access count, register call frequency, and global storage access interval. Local weighted regression is a regression method that constructs a weight model based on the local neighborhood of a sample point. It is suitable for analyzing situations where resource call frequency fluctuates but exhibits local patterns during task execution.

[0094] For each task number to be fitted, record it as , and its fitting access frequency value is expressed as:

[0095] ;

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

[0097] The weight of each sample point Determined by the distance between its number and the target point number, the weight function is defined as:

[0098] ;

[0099] in: : The number of the sample task, for example, T301 is 301; : The task number to be fitted currently; : Smoothing coefficient (also known as bandwidth), which controls the range of the neighborhood. A larger value indicates a wider range of tasks to consider, while a smaller value indicates that only tasks with similar numbers are considered. : A larger weight indicates that the closer the task number is to the target task, the greater the influence of its resource usage data on the fitted value. In practice, samples with numbers closer to the target task are more likely to have similar scheduling times and resource usage patterns, and therefore should be given a higher weight in the regression model. Conversely, a larger number gap indicates a less representative behavior, and the weight is naturally lowered.

[0100] Taking the shared memory access frequency as an example, we perform local weighted regression fitting calculation. The goal is to calculate the frequency of shared memory access for task number The task number sequence is known to be: 301, 302, 303, 304, 305, and the corresponding shared memory access times are: 180, 200, 210, 205, 190. Set the smoothing parameter (bandwidth) to .

[0101] The weight function adopts the Gaussian kernel form, and the calculation formula is:

[0102] ;

[0103] Enter the specific task number and bandwidth :

[0104] Task 301: The number difference is , squared to 4:

[0105] ;

[0106] Task 302: The number difference is , squared to 1:

[0107] ;

[0108] Task 303: Number difference is 0:

[0109] ;

[0110] Task 304: The difference in number is 1, and the square is 1:

[0111] ;

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

[0113] ;

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

[0115] Mission 301: ;

[0116] Mission 302: ;

[0117] Mission 303: ;

[0118] Mission 304: ;

[0119] Mission 305: ;

[0120] Find the weighted sum:

[0121] ;

[0122] Calculate the sum of weights:

[0123] ;

[0124] The fitting value calculation formula is:

[0125] ;

[0126] Therefore, the fitted value of the shared memory access frequency of task number 303 is 203.65, which can be used as an estimated value 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 is determined by the difference in the task numbers. The closer the numbers, the greater the weight, indicating a greater impact of the task on the target task's fitted value. Next, the access frequency of each task is multiplied by its corresponding weight and added together to form the weighted sum. All weights are then added together to form the weighted sum. Finally, the weighted sum is divided by the weighted sum to obtain the fitted value of the current task's access frequency. This fitted value represents the estimated level of shared resource usage within the overall task sequence. This entire process effectively smooths out local fluctuations and reflects the changing patterns of resource access.

[0128] S413: Based on the change trend of shared resource access frequency, determine the first-order derivative of the fitting curve within all task number intervals, select task number groups whose absolute values ​​of the first-order derivatives are lower than the resource access change judgment benchmark value, and obtain a task set with a stable resource contention trend;

[0129] After completing the fitting of the shared resource access frequency change trend, the system needs to perform a first-order derivative analysis on each fitting curve within the task number interval to identify whether the resource access change is stable. During specific execution, the task number is used as the independent variable and the fitting value is used as the dependent variable. The first-order derivative is approximately estimated by the difference between the fitting frequency values ​​of adjacent tasks and the number difference. For example, the fitting frequencies of tasks T401 to T405 are 200, 203, 204, 202, and 201, respectively, and the corresponding numbers are 401 to 405. The derivative between T401 and T402 is calculated as (203-200) / (402-401)=3, the derivative between T402 and T403 is (204-203) / (403-402)=1, the derivative between T403 and T404 is (202-204) / (404-403)=-2, and the derivative between T404 and T405 is (201-202) / (405-404)=-1. The absolute value of each derivative is then taken for screening. If the resource access change threshold is set to 2, all intervals with absolute values ​​less than 2 are retained, and task numbers exceeding the threshold are eliminated. In this example, only the interval T401 to T402 has an absolute value of 3, exceeding the threshold. The values ​​for the remaining intervals are 1, 2, and 1, respectively. With 1 and 2 meeting the boundary conditions, only tasks corresponding to T403 to T405 are retained, forming the set of tasks with stable resource contention trends. This process effectively identifies tasks with slowly changing resource access trends and stable usage behavior.

[0130] See also Figure 6 , the specific steps for obtaining the GPU task resource dynamic allocation list are:

[0131] S511: Obtaining a set of tasks with a stable resource contention trend and address access frequency records within a GPU scheduling cycle, extracting the scheduling sequence number of each task and the residence time of the task instruction migration path segment, establishing a correspondence between the task number, the path segment residence time, and the scheduling sequence, and generating a task resource access association parameter set;

[0132] After identifying a set of tasks with a stable resource contention trend, the system needs to extract associated parameters for each task based on the address access frequency records within the GPU scheduling cycle. The specific process includes three key data: the task's scheduling sequence number, the path segment residence 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 third in the cycle, and T502 is fifth. Then, combined with its path segment residence time information, for example, the sum of the residence times of each path segment of T501 is 18 milliseconds, and that of T502 is 22 milliseconds. Finally, the address access records corresponding to the tasks are matched and their access frequencies are recorded for subsequent mapping evaluation. By integrating the task number, residence time, and scheduling sequence number, a mapping relationship structure between the three is established, for example: T501 → {sequence 3, residence 18}, T502 → {sequence 5, residence 22}, to form a task resource access associated parameter set.

[0133] S512: Based on the task resource access associated parameter set, select the address segments in the address access frequency records whose access frequency values ​​are in the lowest range among all records as candidate mapping targets, sort the path segments corresponding to the tasks from largest to smallest residence time, and generate a task address priority allocation structure table;

[0134] After constructing the task resource access associated parameter set, the system needs to combine the GPU address access frequency data to identify the address segments with the lowest frequency values ​​in all records. These segments are least accessed during the scheduling cycle and have a low probability of resource conflict, making them 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 large to small by the residence time of the task path segment. For example, if the residence time of T502 is 22 milliseconds and that of T501 is 18 milliseconds, the order after sorting is T502, T501, forming a task address priority allocation structure table, that is, the longer the residence time, the closer the task is to the front, and it is preferentially matched to the address segment with higher idleness.

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

[0136] Based on the task address priority allocation structure table, the system will allocate address resources to each task one by one according to the task order, and bind the corresponding low-access frequency address segment numbers in sequence. For example, if the current candidate address segment ranges from 1200 to 1300 and is segmented into blocks of 10 units, then the first task T502 is bound to an address segment starting number 1200, the second task T501 is bound to an address segment starting number 1210, and so on, to ensure that the allocated segments do not overlap. The longer the task resides, the closer the address segment it is bound to, thereby reducing the probability of address access conflicts for high-residence tasks. The system generates a complete GPU task resource dynamic allocation list, which contains the mapping relationship between task numbers and their assigned address segment starting numbers, 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, and 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, and divides the task instruction migration path into segments;

[0139] The migration path duplication identification module pairs and combines the migration path segments of task instructions with the same thread number, determines the duplication degree of migration behaviors between tasks through the longest common subsequence algorithm, and marks the repeated migration path task sets;

[0140] The scheduling interval overlap analysis module obtains the scheduling time of each repeated migration path task set and the sum of the residence 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 dense task groups;

[0141] The resource access trend assessment module obtains the shared resource call frequency of each task in the overlapping and dense task group, determines the changing trend of shared resource access frequency among tasks, identifies the task combination with stable changing trend, and obtains the task set with stable resource contention trend;

[0142] 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 the task number and the 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. When the processor executes the computer program, the device for dynamically allocating and managing GPU server resources as described above is implemented.

[0144] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the above-mentioned method for dynamic allocation and management of GPU server resources.

[0145] The above are merely preferred embodiments of the present invention and do not limit the present invention in any other form. Any technician familiar with the profession may use the technical content disclosed above to change or modify it into an equivalent embodiment with equivalent changes and apply it to other fields. However, any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. A method for dynamically allocating and managing GPU server resources, characterized in that: The following steps are involved: 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, and divide the task instruction migration path segments; S2: Pair and combine the task instruction migration path segments with the same thread number, determine the degree of repetition of migration behaviors between tasks using the longest common subsequence algorithm, and mark the repeated migration path task sets; S3: Obtain the scheduling time of each repeated migration path task set and the sum of the residence 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 out overlapping dense task groups; S4: Obtain the shared resource call frequency of each task in the overlapping dense task group, determine the change trend of the shared resource access frequency among tasks, identify the task combination with a stable change trend, and obtain a task set with a stable resource contention trend; S5: Associating the resource contention trend stable task set with the address access frequency record in the GPU scheduling cycle, determining the allocation correspondence between the task number and the corresponding address segment, and obtaining a GPU task resource dynamic allocation list.

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

3. The method for dynamic allocation and management of GPU server resources according to claim 1, wherein: The steps for obtaining the task instruction migration path segment are specifically as follows: S111: Obtain instruction scheduling records for all tasks within a GPU scheduling cycle, call the execution start position number, jump target position number, and scheduling time corresponding to each instruction, and sort adjacent jump paths in order of scheduling time to obtain a jump path sequence within the task; S112: Based on the jump path sequence within the task, segment boundaries are determined according to the execution interval between paths and the average residence time within the task, and jump paths are divided to obtain jump path division intervals; S113: Divide the jump path into sections, mark the segment number sequence, path number range and residence time of each segment, and associate with the original task number information to obtain the task instruction migration path segment.

4. The method for dynamic allocation and management of GPU server resources according to claim 3, wherein: The steps for obtaining the repeated migration path task set are specifically as follows: S211: Obtain the task instruction migration path segments, classify them according to the thread numbers to which they belong, extract all tasks under the same thread number as combination candidates, pair the task numbers of each candidate task in each group, and generate an intra-thread task pairing sequence group; S212: Extracting the task pairing sequence group within the thread, extracting the migration path segment number sequence of each pair of tasks, calling the longest common subsequence algorithm, performing a bit-by-bit comparison on the order of the path segment numbers in the sequence, obtaining the ratio of the longest common subsequence length of the path segment numbers to the shorter total number of path segment numbers, and using the ratio as a basis for determining the degree of duplication, thereby obtaining a path segment duplication analysis result; S213: According to the path segment duplication analysis result, the task pairing relationships whose ratios exceed the path segment duplication judgment reference value are screened, and a task set with close path segment duplication relationships is identified to obtain a repeated migration path task set.

5. The method for dynamic allocation and management of GPU server resources according to claim 4, wherein: The steps for obtaining the overlapping dense task group are specifically 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, and call the residence time of all path segments in the corresponding task instruction migration path segment data, calculate the total task execution time of each task, and generate a task scheduling time data set; S312: Based on the task scheduling duration data set, combine the start scheduling time and the total task duration according to the task number, record the start and end positions and interval span of each task time period, and generate the task scheduling occupancy interval; S313: According to the task scheduling occupancy interval information, obtain the time range of the GPU scheduling window, determine the scheduling interval intersection time period of each task, calculate the interval overlap ratio between the specified two tasks, and filter the task combinations whose interval overlap ratio is greater than the scheduling overlap judgment benchmark value to obtain the overlapping dense task group.

6. The method for dynamic allocation and management of GPU server resources according to claim 5, wherein: The steps for obtaining the task set with a stable resource contention trend are as follows: S411: Acquire shared resource call data of each task in the overlapping dense task group, extract the number of shared memory accesses, register call frequency, and global storage access interval of the corresponding task, establish a corresponding structure between resource type and access parameter according to the task number, and generate a shared resource call frequency data set; S412: Based on the shared resource call frequency dataset, with the task number as the input order, the access frequency value of each type of shared resource is input as the variable dimension into the local weighted regression algorithm, fitting the change trajectory of the resource access frequency in the task number sequence, obtaining the access frequency fitting curve of each type of resource in the task distribution, and generating the shared resource access frequency change trend; S413: According to the change trend of the shared resource access frequency, determine the first-order derivative of the fitting curve in all task number intervals, select the task number group whose absolute value of the first-order derivative is lower than the resource access change judgment benchmark value, and obtain the task set with a stable resource contention trend.

7. The method for dynamic allocation and management of GPU server resources according to claim 6, wherein: The steps for obtaining the GPU task resource dynamic allocation list 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 residence time of the task instruction migration path segment, establish a correspondence between the task number, the path segment residence time and the scheduling sequence, and generate a task resource access association parameter set; S512: Based on the task resource access associated parameter set, select the address segments in the address access frequency records whose access frequency values ​​are in the lowest range among all records as candidate mapping targets, sort the path segments corresponding to the tasks from largest to smallest residence time, and generate a task address priority allocation structure table; S513: Based on the task address priority allocation structure table, bind each task number to the corresponding address segment starting number in sequence to obtain a GPU task resource dynamic allocation list.

8. A GPU server resource dynamic allocation 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, and divides the task instruction migration path into segments; A migration path duplication identification module pairs and combines the task instruction migration path segments of the same thread number, determines the duplication degree of migration behaviors between tasks through the longest common subsequence algorithm, and marks the repeated migration path task set; The scheduling interval overlap analysis module obtains the scheduling time of each repeated migration path task set and the sum of the residence 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 the overlapping dense task group; A resource access trend assessment module obtains the shared resource call frequency of each task in the overlapping intensive task group, determines the changing trend of the shared resource access frequency among tasks, identifies the task combination with a stable changing trend, and obtains a task set with a stable resource contention trend; The address resource dynamic allocation module associates the resource contention trend stable task set with the address access frequency record in the GPU scheduling cycle, determines the allocation correspondence between the task number and the 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 the processor implements the GPU server resource dynamic allocation management device according to claim 8 when executing the computer program.

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

Images