Dynamic CPU scheduling method, system and device based on CPU busy state and medium

Abstract

The invention relates to a dynamic CPU scheduling method, system and device based on a CPU busy state and a medium. The method comprises the steps that busy degree indexes of all CPU cores are dynamically generated through monitoring; service logic to be executed is analyzed into a task set, and task attributes which cannot be changed are distributed to tasks; determining respective target CPU cores based on busy degree indexes of all current tasks, generating binding parameters, and writing the binding parameters into task attributes of the corresponding tasks; executing the allocation logic according to the task attribute of each task, and submitting the task to a running queue of the target CPU core to wait for execution; and when the single execution duration of the task in the target CPU core reaches a preset threshold value or is terminated by external interruption, resetting the corresponding task into the operation queue. According to the invention, breakthrough improvement is realized in three dimensions of hardware resource utilization rate, system real-time performance and scheduling security, and a solution with response speed and stability is provided for task scheduling in a computing environment.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a dynamic CPU scheduling method, system, device, and medium based on the busy state of the CPU. Background Art

[0002] In the field of real-time operating systems, the Linux kernel optimizes the system scheduling mechanism by integrating the preempt-rt patch, making task scheduling preemptible, thereby providing a priority-based interrupt handling mechanism and threaded interrupt service routines for real-time tasks.

[0003] However, in high-concurrency load scenarios, the existing scheduling algorithms still mainly rely on static priority queues and simple load balancing algorithms for task allocation strategies. Due to the lack of dynamic awareness of the load status of CPU cores by traditional schedulers, when the system faces sudden high loads, task allocation often follows preset static rules. This mechanism is difficult to capture the actual workload fluctuations of each CPU core in real time, so there may be an imbalance in the allocation of computing resources - when some cores are running at full load, there are still redundant schedulable resources on the remaining cores. This imbalance in resource utilization not only prolongs the response latency of high-priority tasks but also further exacerbates the decline in the overall system throughput due to the context switching overhead caused by task migration between cores. Summary of the Invention

[0004] (1) Technical Problems to be Solved

[0005] In view of the above-mentioned shortcomings and deficiencies of the prior art, the present invention provides a dynamic CPU scheduling method, system, device, and medium based on the busy state of the CPU, which solves the technical problems that the existing scheduling mechanism lacks the dynamic awareness of the load status of CPU cores, resulting in uneven task allocation in high-load scenarios, leading to an imbalance in the utilization of core resources and a decline in system real-time performance.

[0006] (2) Technical Solutions

[0007] To achieve the above object, the main technical solutions adopted by the present invention include:

[0008] In the first aspect, an embodiment of the present invention provides a dynamic CPU scheduling method based on the CPU busy degree, including:

[0009] Monitoring the running state parameters of each CPU core and dynamically generating the busy degree index of each CPU core;

[0010] Parsing the business logic to be executed into a task set and assigning immutable task attributes to the tasks in the task set;

[0011] Determine the respective target CPU cores based on the busyness metrics of all current tasks, and generate binding parameters to be written into the task attributes of the corresponding tasks, forming a static association relationship between the tasks and the CPU cores;

[0012] Execute the allocation logic according to the task attributes of each task, and submit the tasks to the run queue of the target CPU cores to wait for execution;

[0013] When the single execution duration of a task on the target CPU core reaches a preset threshold or is terminated by an external interrupt, put the corresponding task back into the run queue to trigger a new round of scheduling.

[0014] Optionally, monitor the operating status parameters of each CPU core, and dynamically generate the busyness metrics of each CPU core, including:

[0015] Divide a configurable time window into multiple consecutive sub-time slices;

[0016] At the end of each sub-time slice, by reading the register value of the hardware performance counter, count the actual busy duration of the sub-time slice;

[0017] Detect the number of hardware interrupt triggers within each sub-time slice. If the number of interrupts exceeds the set threshold, activate the forced compensation mechanism;

[0018] When the forced compensation mechanism is activated, determine the compensation coefficient according to the ratio of the executed time to the remaining unexecuted time of the corresponding sub-time slice, where the value of the compensation coefficient is inversely proportional to the remaining time ratio;

[0019] Take the product of the compensation coefficient and the remaining unexecuted time of the corresponding sub-time slice as the compensation increment, and add it to the actual busy duration to obtain the corrected busy duration, so that the corrected busy duration includes the implicit processing overhead caused by high-frequency interrupts; if the accumulated corrected busy duration exceeds the total length of the current sub-time slice, defer the overflow part of the duration to the next sub-time slice, and deduct the overflow part of the duration in advance at the initial moment of the next sub-time slice as the compensation increment;

[0020] Accumulate the corrected busy durations of all sub-time slices within the time window, and add the context switch compensation time caused by cross-time slice task migration to obtain the total busy time;

[0021] Calculate the original busyness value within the current time window based on the total busy time, and introduce an exponentially weighted moving average model to fuse the original busyness value within the current time window with the busyness value of the previous time window to obtain the final busyness metric;

[0022] Optionally, parse the business logic to be executed into a task set, and assign immutable task attributes to the tasks in the task set, including:

[0023] Analyze the communication relationships and shared resource dependencies of threads in the business logic to be executed, and construct a task relationship graph. Among them, the nodes in the task relationship graph represent the tasks in the task set, and the edge weights represent the actual data volume transmitted between tasks;

[0024] Calculate the priority baseline value according to the out-degree and in-degree of each node;

[0025] Perform topological sorting to determine the depth value representing the number of the longest path edges from each node's representative node to the starting node, and perform a stepped incremental correction on the priority baseline value of each node according to the depth value;

[0026] Generate a multi-dimensional resource vector for each task, including computing requirements, memory requirements, storage requirements, and cache requirements;

[0027] Generate an attribute tuple containing the priority correction value and the multi-dimensional resource vector;

[0028] Use an asymmetric encryption algorithm to digitally sign the attribute tuple, and write the signature result into the non-modifiable area of the task control block.

[0029] Optionally, determine the target CPU core for each task based on the busyness metrics of all current tasks, and generate binding parameters to be written into the task attributes of the corresponding tasks, forming a static association relationship between tasks and CPU cores, including:

[0030] Real-time obtain the current busyness metrics of all CPU cores, and calculate the global average busyness and the fluctuation standard deviation;

[0031] Filter out all CPU cores whose busyness metrics exceed the first dynamic overload threshold to form a candidate pool of available cores; among them, the value of the first dynamic overload threshold is the sum of the average busyness and twice the standard deviation;

[0032] For each core in the candidate pool, combine the obtained remaining resource information and processing rate, and hand it over to a pre-trained neural network for future load prediction;

[0033] Select the core with the smallest predicted load as the main binding target, and at the same time select standby cores that meet the set load conditions from different memory access domains;

[0034] Generate a triple binding parameter containing the main core number, standby core number, and timestamp;

[0035] Encapsulate and encrypt the generated triple binding parameter, and use asymmetric encryption to generate an irreversible digital envelope;

[0036] Write the generated digital envelope into the task control block, and attach a uniqueness verification code based on a hardware random number to register it to the scheduler kernel module;

[0037] Establish an associated mapping between the binding parameters and the task ID in the scheduling kernel module to ensure its validity only within the task life cycle.

[0038] Optionally, when it is detected that the busyness metric of the target CPU core exceeds the second dynamic overload threshold, which is 95% of the first dynamic overload value, for N consecutive cycles, the following steps are executed:

[0039] Generate a core overload event and trigger the process of regenerating the triple binding parameters;

[0040] Add the spare core number again from different memory access domains;

[0041] Preferentially use the spare core to execute when the task starts.

[0042] Optionally, execute the allocation logic according to the task attributes of each task, and submit the task to the run queue of the target CPU core for waiting to execute, including:

[0043] Determine the maximum allowable length of the run queue according to the real-time processing rate of the main core of the obtained target CPU core and the estimated execution time of the task;

[0044] If the load of the run queue reaches the preset load threshold, automatically redirect the task to the buffer queue of the spare core of the target CPU core;

[0045] If the load of the run queue does not reach the preset load threshold, calculate the sorting score based on the priority correction value, multi-dimensional resource vector in the task attributes of each task, and the waiting time of the target CPU core;

[0046] Before the task enters the queue, perform the verification of the digital signature validity and binding timeliness, freeze and isolate the task with failed verification, trigger the regeneration of the allocation attributes, and retain the original task context data;

[0047] After submitting the task to the run queue of the target CPU core according to the sorting score, periodically scan the queue status.

[0048] Optionally, when the single execution duration of the task on the target CPU core reaches the preset threshold or is terminated by an external interrupt, re-insert the corresponding task into the run queue to trigger a new round of scheduling, including:

[0049] Real-time monitor the running status of the task on the target CPU core, and capture the actual execution duration through the hardware performance counter;

[0050] When it is detected that the actual execution duration exceeds the preset threshold or an external interrupt signal is received, generate an abnormal termination event identifier, suspend the task execution and trigger the saving of the context snapshot including register status, memory page table and cache line information;

[0051] Mark the abortion type code in the task control block and associate the snapshot data of the target CPU core load at the moment when the event occurs;

[0052] Select the enqueue policy for tasks with abortion event identifiers according to the real-time queue load status of the current target core:

[0053] If the load of the main core queue of the target CPU core is lower than the preset light load threshold, give priority to inserting it at the head of the original queue;

[0054] If the main core queue of the target CPU core is higher than the preset heavy load threshold, divert it to the buffer queue of the spare core of the target CPU core.

[0055] In a second aspect, an embodiment of the present invention provides a dynamic CPU scheduling system based on CPU busyness, including:

[0056] A busyness calculation module, configured to monitor the operating state parameters of each CPU core and dynamically generate the busyness metrics of each CPU core;

[0057] An attribute assignment module, configured to parse the business logic to be executed into a task set and assign immutable task attributes to the tasks in the task set;

[0058] A static association module, configured to determine the respective target CPU cores based on the busyness metrics of all current tasks and generate binding parameters to be written into the task attributes of the corresponding tasks, forming a static association relationship between tasks and CPU cores;

[0059] An assignment execution module, configured to execute the assignment logic according to the task attributes of each task and submit the tasks to the run queue of the target CPU core for waiting to be executed;

[0060] A rescheduling module, configured to, when the single execution duration of a task on the target CPU core reaches a preset threshold or is terminated by an external interruption, re-insert the corresponding task into the run queue to trigger a new round of scheduling.

[0061] In a third aspect, an embodiment of the present invention provides a dynamic CPU scheduling device based on CPU busyness, including:

[0062] At least one processor;

[0063] And a memory communicatively connected to the at least one processor;

[0064] Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the dynamic CPU scheduling method based on CPU busyness as described above.

[0065] Fourthly, an embodiment of the present invention provides a computer-readable storage medium, on which computer-executable instructions are stored. When the executable instructions are executed by a processor, the dynamic CPU scheduling method based on the CPU busyness degree as described above is implemented.

[0066] (III) Beneficial effects

[0067] The beneficial effects of the present invention are as follows:

[0068] First of all, the present invention first collects the operating state parameters of the CPU core and constructs a dynamic busyness index, solving the problem that the traditional static load evaluation model cannot reflect the core load fluctuation in real time. On this basis, when parsing the business logic into a task set, by introducing an immutable task attribute binding mechanism, an immutable binding relationship is formed. This dual mechanism of "dynamic selection - static binding" not only retains the fast response ability of the real-time scheduling strategy to system load changes, but also greatly reduces the task switching overhead by restricting the core migration behavior during secondary scheduling. Especially in high-concurrency scenarios, it effectively avoids the cache thrashing problem caused by frequent migrations.

[0069] Furthermore, execute multi-dimensional allocation logic according to task attributes, and implement load scheduling in combination with the real-time state of the target core queue, so that the corresponding quality level of tasks can still be maintained in high-load scenarios, ensuring the real-time performance of high-priority tasks while ensuring the stability of scheduling.

[0070] Finally, combined with the intelligent re-entry strategy for abnormal tasks, a closed-loop adaptive scheduling optimization ability is formed. When a task exits due to timeout or interruption, it not only triggers dynamic priority correction, but also can automatically optimize the binding rules based on historical execution data. This enables the utilization rate difference between cores to be maintained at less than 15% in a continuous high-load environment, greatly reducing the risk of resource imbalance compared with traditional methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 is a schematic flowchart of the method provided by the embodiment of the present invention;

[0072] Figure 2 is a specific schematic flowchart of step S1 of the method provided by the embodiment of the present invention;

[0073] Figure 3 is a specific schematic flowchart of step S2 of the method provided by the embodiment of the present invention;

[0074] Figure 4 is a specific schematic flowchart of step S3 of the method provided by the embodiment of the present invention;

[0075] Figure 5 is a specific schematic flowchart of step S4 of the method provided by the embodiment of the present invention;

[0076] Figure 6 It is a schematic flowchart of step S5 of the method provided by the embodiment of the present invention;

[0077] Figure 7 It is a schematic diagram of the overall process of the method provided by the embodiment of the present invention. Detailed implementation manners

[0078] To better explain the present invention for easy understanding, the present invention will be described in detail below in conjunction with the accompanying drawings through specific implementation manners.

[0079] Before that, to facilitate understanding of the technical solution provided by the present invention, some concepts will be introduced below.

[0080] Real-time Linux kernel: It refers to the Linux kernel modified by the real-time patch (preempt-rt), which provides higher scheduling priorities and shorter interrupt handling times.

[0081] preempt-rt: Real-time patch, used to improve the real-time performance of the Linux kernel and allow the kernel to be preempted at any point in time.

[0082] As Figure 1 shown, a dynamic CPU scheduling method based on the CPU busyness degree proposed by the embodiment of the present invention includes: monitoring the running state parameters of each CPU core, dynamically generating the busyness indicators of each CPU core; parsing the business logic to be executed into a task set, and assigning immutable task attributes to the tasks in the task set; determining the target CPU core for each task based on the busyness indicators of all current tasks, and generating binding parameters to be written into the task attributes of the corresponding tasks to form a static association relationship between the tasks and the CPU cores; executing the allocation logic according to the task attributes of each task, and submitting the tasks to the run queue of the target CPU core to wait for execution; when the single execution duration of a task on the target CPU core reaches a preset threshold or is terminated by an external interrupt, putting the corresponding task back into the run queue to trigger a new round of scheduling.

[0083] First, the present invention first constructs a dynamic busyness indicator by collecting the running state parameters of the CPU core, solving the problem that the traditional static load evaluation model cannot reflect the core load fluctuation in real time. On this basis, when parsing the business logic into a task set, by introducing an immutable task attribute binding mechanism, an immutable binding relationship is formed. This dual mechanism of "dynamic selection - static binding" not only retains the fast response ability of the real-time scheduling strategy to system load changes, but also greatly reduces the task switching overhead by restricting the core migration behavior during secondary scheduling, especially effectively avoiding the cache jitter problem caused by frequent migrations in high-concurrency scenarios.

[0084] Furthermore, a multi-dimensional allocation logic is executed according to the task attributes, and the load scheduling is implemented in combination with the real-time state of the target core queue, so that the corresponding quality level of the task can still be maintained under high-load scenarios. While ensuring the real-time performance of high-priority tasks, the stability of the scheduling is ensured.

[0085] Finally, combined with the intelligent re-entry strategy for abnormal tasks, a closed-loop adaptive scheduling optimization ability is formed. When a task exits due to timeout or interruption, it not only triggers dynamic priority correction, but also can automatically optimize the binding rules based on historical execution data, which enables the utilization rate difference between cores to remain less than 15% in a continuously high-load environment, greatly reducing the risk of resource imbalance compared with traditional methods.

[0086] To better understand the above technical solution, the exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more clear and thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.

[0087] Specifically, an embodiment of the present invention provides a dynamic CPU scheduling method based on the CPU busyness degree, including:

[0088] S1. Monitor the operating state parameters of each CPU core and dynamically generate the busyness index of each CPU core.

[0089] Furthermore, as Figure 2 shown, step S1 includes:

[0090] S11. Divide a configurable time window into multiple consecutive sub-time slices.

[0091] S12. At the end of each sub-time slice, by reading the register value of the hardware performance counter, count the actual busy duration of the sub-time slice.

[0092] In the periodic sampling stage, the present invention sets a configurable time window T, where T ∈ [5ms, 50ms] and dynamic adjustment is allowed. T is divided into m consecutive sub-time slices, satisfying m ≥ 10 and the length of each sub-time slice Δt = T / m ≤ 5ms; at the end of each sub-time slice, by reading the value of the CPUIDLE_STATE register of the CPU hardware performance counter, count the actual busy duration t b and the idle duration t i .

[0093] It should be clear that the actual busy duration is the total time when the CPU core executes non-idle tasks within a sub-time slice, including the execution time of user-mode processes, the kernel-mode interrupt service time, and the non-preemptible scheduler running time; the idle duration is the total time when the CPU core is in an idle state or executes idle loop instructions within a sub-time slice.

[0094] S13. Detect the number of hardware interrupt triggers within each sub-time slice. If the number of interrupts exceeds the set threshold, activate the forced compensation mechanism.

[0095] S14. When the forced compensation mechanism is activated, determine the compensation coefficient according to the ratio of the executed time to the remaining unexecuted time of the corresponding sub-time slice, where the value of the compensation coefficient is inversely proportional to the remaining time ratio.

[0096] S15. Take the product of the compensation coefficient and the remaining unexecuted time of the corresponding sub-time slice as the compensation increment, and add it to the actual busy duration to obtain the corrected busy duration, so that the corrected busy duration includes the implicit processing overhead caused by high-frequency interrupts; if the accumulated corrected busy duration exceeds the total length of the current sub-time slice, defer the overflow part of the duration to the next sub-time slice, and deduct the overflow part of the duration in advance at the initial moment of the next sub-time slice as the compensation increment.

[0097] In this step, when forced compensation is triggered, the actual busy duration of this sub-time slice is corrected to: t b ' = t b + k × Δt r , where k ∈ [0.5, 1.5] is the compensation coefficient, and Δt r is the remaining unexecuted time of this sub-time slice. Triggering time slice compensation through the number of hardware interrupts solves the problem of underestimated busy degree caused by interrupt storms in traditional monitoring methods.

[0098] S16. Accumulate the corrected busy durations of all sub-time slices within the time window, and supplement the context switch compensation time generated by cross-time slice task migration to obtain the total busy time. For the first time, the implicit overhead of task migration is incorporated into the load evaluation system, making the busy degree index closer to the actual computing resource consumption.

[0099] S17. Calculate the original busy degree value within the current time window based on the total busy time, and introduce an exponentially weighted moving average model to fuse the original busy degree value within the current time window with the busy degree value of the previous time window to obtain the final busy degree index.

[0100] In this step, accumulate the corrected busy durations of all sub-time slices within the time window T to obtain the total window busy time: T b = Σ(t b ) + Σ(Δt c), where Δt c is the context switch compensation time caused by cross-time slice task migration, and the compensation value is calculated by increasing 0.1 ms for each migration; then, calculate the original busy degree of the current window: B r =(T b / T)×100%, furthermore, introduce the exponentially weighted moving average model to fuse the current window busy degree with the historical value: B c =α×B r +(1-α)×B p +ε, where α∈[0.4,0.6] is the dynamic decay factor, B p is the busy degree value of the previous time window, and ε is the offset adjusted according to the CPU frequency scaling factor f s , satisfying: ε = 0.5×(f s / f b -1), f b is the CPU nominal base frequency. Introducing the ε offset related to CPU dynamic frequency modulation can automatically increase the busy degree estimation value when the core frequency drops, avoiding misjudgment of "false idle" caused by frequency reduction, and realizing the linkage optimization of the hardware power consumption state and the scheduling strategy.

[0101] S2. Parse the business logic to be executed into a task set, and assign immutable task attributes to the tasks in the task set.

[0102] Further, as Figure 3 shown, step S2 includes:

[0103] S21. Analyze the communication relationship and shared resource dependency relationship of the threads in the business logic to be executed, and construct a task relationship graph, where the nodes in the task relationship graph represent the tasks in the task set, and the edge weights represent the actual data transmission volume between tasks.

[0104] S22. Calculate the priority reference value according to the out-degree and in-degree of each node.

[0105] In this step, count the out-degree value O i (the number of successor tasks pointed to by the current node) and the in-degree value I i (the number of predecessor tasks pointing to the current node) for each node, and calculate the initial priority reference value for each node: P base =a×O i -b×I i, where the coefficients a ∈ [0.8, 1.2] and b ∈ [0.3, 0.7], and through experimental calibration, a = 1.0 and b = 0.5 are preferably selected. An initial reward value of 20 is applied to the root node (in-degree = 0) to ensure the priority scheduling of tasks without dependencies. In this way, through the differential out-degree and in-degree, the priority of nodes with more successor tasks is strengthened, and the weight of nodes with more predecessor dependencies is weakened, avoiding scheduling delays caused by complex dependency chains.

[0106] S23. Perform topological sorting to determine the depth value representing the number of the longest path edges from each node to the starting node, and perform stepwise incremental correction on the priority reference value of each node according to the depth value.

[0107] Specifically, execute the topological sorting algorithm, starting from the root node of the task relationship graph, and calculate the depth value d of each node layer by layer i , where: d i = max{d j + w ji | j is the predecessor node of i} w ji is the weight of the edge j → i, representing the data transmission overhead from task j to i.

[0108] Record the maximum depth value d of each node max , representing the cumulative weight of the longest path from this node to the end point.

[0109] Divide the depth values into multiple interval levels (for example, every 10 weight units is one level), and apply non-linear increments according to the levels:

[0110] When d max ∈ [0, 10), ΔP depth = 5 × d max ;

[0111] When d max ∈ [10, 20), ΔP depth = 50 + 3 × (d max - 10);

[0112] When d max ≥ 20, ΔP depth = 80 + 2 × (d max - 20).

[0113] In this way, by using interval processing of depth values and decreasing incremental design, the over-inflation of the priority of tail tasks is avoided, and at the same time, sufficient scheduling advantages are ensured for the tasks at the head of the critical path.

[0114] S24. Generate a multi-dimensional resource vector for each task, including computing requirements, memory requirements, storage requirements, and cache requirements.

[0115] S25. Generate an attribute tuple containing a priority correction value and a multi-dimensional resource vector.

[0116] S26. Use an asymmetric encryption algorithm to digitally sign the attribute tuple and write the signature result to the non-modifiable area of the task control block.

[0117] S3. Determine the respective target CPU cores based on the busy degree metrics of all current tasks, and generate binding parameters to be written into the task attributes of the corresponding tasks, forming a static association relationship between tasks and CPU cores.

[0118] Furthermore, as Figure 4 shown, step S3 includes:

[0119] S31. Real-time obtain the current busy degree metrics of all CPU cores, and calculate the global average busy degree and the standard deviation of fluctuations.

[0120] Among them, calculate the global average busy degree: B avg =(ΣB i ) / n, where n is the number of metrics, and calculate the standard deviation of fluctuations σ = sqrt(Σ(B i -B avg ) 2 / (n - 1)).

[0121] S32. Screen out the CPU cores whose busy degree metrics exceed the first dynamic overload threshold to form a candidate pool of available cores; among them, the value of the first dynamic overload threshold is the sum of the average busy degree and twice the standard deviation.

[0122] S33. For each core in the candidate pool, combine the obtained remaining resource information and processing rate, and hand it over to a pre-trained neural network for future load prediction.

[0123] Combine the resource feature vector of the candidate core with the real-time processing rate data into a prediction input vector, and input it into the pre-trained neural network model; the neural network outputs the predicted load value within the future time window, and the historical load data and the abnormal interruption event annotation set are used during model training.

[0124] S34. Select the core with the minimum predicted load as the main binding target, and at the same time select standby cores that meet the set load conditions from different memory access domains.

[0125] Specifically, the selection conditions for the standby cores are:

[0126] a. The memory access domain to which it belongs is different from that of the main core;

[0127] b. The current busy degree ≤ B avg -σ;

[0128] c. The memory bandwidth margin ≥ 0.7 times the maximum memory bandwidth.

[0129] S35. Generate triple binding parameters including a primary core number, a backup core number, and a timestamp.

[0130] S36. Encrypt and package the generated triple binding parameters, and generate an irreversible digital envelope using asymmetric encryption.

[0131] S37. Write the generated digital envelope into the task control block, and attach a uniqueness verification code based on a hardware random number to register it in the scheduler kernel module. Here, the digital envelope technology is combined with timestamp verification to ensure that the bound core number is both tamper-proof (guaranteed by asymmetric encryption) and can automatically expire.

[0132] S38. Establish an association mapping between the binding parameters and the task ID in the scheduling kernel module to ensure validity only within the task life cycle.

[0133] In addition, when it is detected that the busyness metric of the target CPU core exceeds the second dynamic overload threshold, which is 95% of the first dynamic overload value, for N consecutive cycles, the following steps are executed: generate a core overload event and trigger the process of regenerating the triple binding parameters; add the backup core number again from different memory access domains; preferentially use the backup core to execute when the task starts.

[0134] S4. Execute the allocation logic according to the task attributes of each task, and submit the task to the run queue of the target CPU core to wait for execution.

[0135] Further, as Figure 5 shown, step S4 includes:

[0136] S41. Determine the maximum allowable length of the run queue according to the real-time processing rate of the primary core of the target CPU core obtained and the estimated execution time of the task.

[0137] In a specific embodiment, obtain the real-time frequency f c of the target primary core and the theoretical maximum frequency f max , and calculate the primary core processing rate factor η = f c / f max . Dynamically set the maximum queue length according to the formula: L max = [(η × C base × T slice ) / t est , where C base is the benchmark processing capacity unit, T slice = 100ms is the scheduling period, and t est is the estimated execution time of the task.

[0138] S42. When the load of the running queue reaches the preset load threshold, automatically redirect the task to the buffer queue of the standby core of the target CPU core.

[0139] S43. When the load of the running queue does not reach the preset load threshold, calculate the sorting score based on the priority correction value, multi-dimensional resource vector in the task attributes of each task, and the waiting time of the target CPU core.

[0140] S44. Before the task enters the queue, perform the verification of the digital signature validity and binding timeliness, freeze and isolate the task with failed verification, trigger the regeneration of the allocation attributes, and retain the original task context data.

[0141] S45. After submitting the task to the running queue of the target CPU core according to the sorting score, periodically scan the queue status, such as the average waiting time, task discard rate status information, etc.

[0142] S5. When the single execution duration of the task on the target CPU core reaches the preset threshold or is terminated by an external interruption, re-insert the corresponding task into the running queue to trigger a new round of scheduling.

[0143] Further, as Figure 6 shown, step S5 includes:

[0144] S51. Real-time monitor the running status of the task on the target CPU core, and capture the actual execution duration through the hardware performance counter.

[0145] S52. When it is detected that the actual execution duration exceeds the preset threshold or an external interruption signal is received, generate an abnormal termination event identifier, suspend the task execution and trigger the saving of the context snapshot including the register status, memory page table, and cache line information. By saving the complete context snapshot and core load data, it provides a refined decision-making basis for subsequent scheduling and avoids repeated exceptions caused by state loss in traditional methods.

[0146] S53. Mark the abnormal termination type code in the task control block and associate the snapshot data of the target CPU core load at the moment when the event occurs.

[0147] S54. Select the enqueue strategy for the task with the abnormal termination event identifier according to the real-time queue load status of the current target core:

[0148] If the load of the main core queue of the target CPU core is lower than the preset light load threshold, give priority to inserting it at the head of the original queue;

[0149] If the main core queue of the target CPU core is higher than the preset heavy load threshold, divert it to the buffer queue of the standby core of the target CPU core.

[0150] In this way, by selecting the main / backup queue insertion position in combination with the real-time load status, while avoiding queue oscillation, the quality of service for high-priority tasks is ensured.

[0151] Additionally, an embodiment of the present invention provides a dynamic CPU scheduling system based on the CPU busyness degree, including:

[0152] A busyness calculation module, configured to monitor the operating state parameters of each CPU core and dynamically generate the busyness metrics of each CPU core.

[0153] An attribute assignment module, configured to parse the business logic to be executed into a task set and assign immutable task attributes to the tasks in the task set.

[0154] A static association module, configured to determine the respective target CPU cores based on the busyness metrics of all current tasks and generate binding parameters to be written into the task attributes of the corresponding tasks, forming a static association relationship between the tasks and the CPU cores.

[0155] An allocation and execution module, configured to execute the allocation logic according to the task attributes of each task and submit the tasks to the run queue of the target CPU core for waiting to be executed.

[0156] A rescheduling module, configured to, when the single execution duration of a task on the target CPU core reaches a preset threshold or is terminated by an external interruption, re-insert the corresponding task into the run queue to trigger a new round of scheduling.

[0157] Moreover, an embodiment of the present invention provides a dynamic CPU scheduling device based on the CPU busyness degree, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the dynamic CPU scheduling method based on the CPU busyness degree as described above.

[0158] Furthermore, an embodiment of the present invention provides a computer-readable storage medium, on which computer-executable instructions are stored, and when the executable instructions are executed by a processor, the dynamic CPU scheduling method based on the CPU busyness degree as described above is implemented.

[0159] In a specific embodiment, the following configuration is adopted to test the method of the present invention: Test environment: OpenEuler system; Test tool: cyclictest; Test worker threads: 12 - 15 threads; Test duration: 24h; Test data: unit us.

[0160] The following Tables 1 - 5 are the direct test data after applying the Preempt-rt patch to the Linux kernel, and Tables 6 - 9 are the test data after applying the Preempt-rt patch to the Linux kernel and adding the CPU scheduling algorithm implemented in this paper.

[0161] Measured data for Scenario 1:

[0162] Test data for the 1st round in Table 1

[0163]

[0164] Average value of maximum latency: 15.07 us.

[0165] Test data for the 2nd round in Table 2

[0166]

[0167] Average value of maximum latency: 15.75 us.

[0168] Test data for the 3rd round in Table 3

[0169]

[0170] Average value of maximum latency: 16.00 us.

[0171] Test data for the 4th round in Table 4

[0172]

[0173] Average value of maximum latency: 17.25 us.

[0174] Test data for the 5th round in Table 5

[0175]

[0176] Average value of maximum latency: 16.25 us.

[0177] Measured data for Scenario 2:

[0178] Test data for the 1st round in Table 6

[0179]

[0180] Average value of maximum latency: 12.17 us.

[0181] Test data for the 2nd round in Table 7

[0182]

[0183] Average value of maximum latency: 11.41 us.

[0184] Test data for the 3rd round in Table 8

[0185]

[0186] Average maximum latency: 11.67 us.

[0187] Test data for the 4th round in Table 9

[0188]

[0189] Average maximum latency: 12.00 us.

[0190] In summary, the embodiments of the present invention provide a dynamic CPU scheduling method, system, device, and medium based on the busy state of the CPU. Referring to Figure 7 it can be seen that the overall process is as follows: Parse the input actual business logic (such as real-time data processing requests) into a schedulable task set. Each task is encapsulated into a sched_task structure. Traverse the task set, select the optimal target core based on the real-time busy degree, write the core number as an immutable parameter into the task attributes to ensure the fixation of the binding relationship during subsequent scheduling processes, and subsequent repeated scheduling of tasks will not be modified. Then, calculate the target CPU cores of each task, provide the CPU numbers, and execute the scheduling and allocation logic according to the allocation attributes of the tasks. The running queues on the CPUs queue up waiting to be executed. When the single execution duration of a task reaches the upper limit or the task is forcibly ended, it will enter the queue waiting to trigger the next round of scheduling.

[0191] Overall, the present invention realizes a breakthrough improvement in three dimensions: hardware resource utilization, system real-time performance, and scheduling security through the technical chain of "dynamic perception - static binding - elastic execution - closed-loop optimization", providing a new generation of solutions with both response speed and stability for task scheduling in heterogeneous computing environments.

[0192] Since the system / device described in the above embodiments of the present invention is the system / device adopted for implementing the method in the above embodiments of the present invention, based on the method described in the above embodiments of the present invention, those skilled in the art can understand the specific structure and variations of the system / device, and thus will not be elaborated herein. Any system / device adopted for the method in the above embodiments of the present invention falls within the scope of protection of the present invention.

[0193] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, system, or computer program product. Therefore, the present invention can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0194] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions, and the combination of flows and / or blocks in the flowcharts and / or block diagrams can also be implemented by computer program instructions.

[0195] It should be noted that in the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of other elements or steps not listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention can be implemented by means of hardware including several different elements, and by means of a suitably programmed computer. In a claim listing several means, several of these means can be embodied by the same piece of hardware. The use of the words first, second, third, etc. is only for convenience of expression and does not denote any order. These words can be construed as part of the name of the element.

[0196] In addition, it should be noted that in the description of this specification, the descriptions of the terms "an embodiment", "some embodiments", "embodiments", "examples", "specific examples", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic descriptions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples.

[0197] Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications after learning the basic creative concept. Therefore, the claims should be construed to include the preferred embodiments and all changes and modifications falling within the scope of the present invention.

[0198] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention should also include these modifications and variations.

Claims

1. A dynamic CPU scheduling method based on the CPU busy degree, characterized in that Including: Monitoring the operating status parameters of each CPU core and dynamically generating the busyness metrics of each CPU core; Parsing the business logic to be executed into a task set and assigning immutable task attributes to the tasks in the task set; Determining the target CPU core for each task based on the busyness metrics of all current tasks and generating binding parameters to be written into the task attributes of the corresponding tasks, forming a static association relationship between tasks and CPU cores; Executing the allocation logic according to the task attributes of each task and submitting the tasks to the run queue of the target CPU core for waiting to be executed; When the single execution duration of a task on the target CPU core reaches a preset threshold or is terminated by an external interruption, putting the corresponding task back into the run queue to trigger a new round of scheduling.

2. The dynamic CPU scheduling method based on CPU busy degree according to claim 1, wherein Monitoring the operating status parameters of each CPU core and dynamically generating the busyness metrics of each CPU core includes: Dividing a configurable time window into multiple consecutive sub-time slices; At the end of each sub-time slice, by reading the register value of the hardware performance counter, counting the actual busy duration of the sub-time slice; Detecting the number of hardware interrupt triggers within each sub-time slice, and if the number of interrupts exceeds a set threshold, activating a forced compensation mechanism; When the forced compensation mechanism is activated, determining a compensation coefficient according to the ratio of the executed time to the remaining unexecuted time of the corresponding sub-time slice, where the value of the compensation coefficient is inversely proportional to the remaining time ratio; Taking the product of the compensation coefficient and the remaining unexecuted time of the corresponding sub-time slice as a compensation increment and adding it to the actual busy duration to obtain a corrected busy duration; if the accumulated corrected busy duration exceeds the total length of the current sub-time slice, deferring the overflow duration to the next sub-time slice and deducting the overflow duration in advance at the initial moment of the next sub-time slice as a compensation increment; Accumulating the corrected busy durations of all sub-time slices within the time window and adding the context switch compensation time generated due to cross-time slice task migration to obtain the total busy time; Calculating the original busyness value within the current time window based on the total busy time and introducing an exponentially weighted moving average model to fuse the original busyness value within the current time window with the busyness value of the previous time window to obtain the final busyness metric.

3. The dynamic CPU scheduling method based on CPU busy level as claimed in claim 1, wherein Parsing the business logic to be executed into a task set and assigning immutable task attributes to the tasks in the task set includes: Analyzing the communication relationship and shared resource dependency relationship of threads in the business logic to be executed, and constructing a task relationship graph, where the nodes in the task relationship graph represent the tasks in the task set and the edge weights represent the actual data volume transmitted between tasks; Calculating the priority reference value according to the out-degree and in-degree of each node; Performing topological sorting to determine the depth value representing the number of the longest path edges from the node to the starting node of each node, and making a stepped incremental correction to the priority reference value of each node according to the depth value; Generating a multi-dimensional resource vector for each task, including computing requirements, memory requirements, storage requirements, and cache requirements; Generating an attribute tuple including the priority correction value and the multi-dimensional resource vector; Using an asymmetric encryption algorithm to digitally sign the attribute tuple and writing the signature result into the non-modifiable area of the task control block.

4. The dynamic CPU scheduling method based on CPU busy degree according to claim 1, wherein Determine their respective target CPU cores based on the busyness metrics of all current tasks, generate binding parameters and write them into the task attributes of the corresponding tasks, and form a static association relationship between tasks and CPU cores, including: Obtain the current busyness metrics of all CPU cores in real time, and calculate the global average busyness and the standard deviation of fluctuations; Filter out all CPU cores whose busyness metrics exceed the first dynamic overload threshold to form a candidate pool of available cores; among them, the value of the first dynamic overload threshold is the sum of the average busyness and twice the standard deviation; For each core in the candidate pool, combine the obtained remaining resource information and processing rate, and hand it over to a pre-trained neural network for future load prediction; Select the core with the smallest predicted load as the main binding target, and at the same time select standby cores that meet the set load conditions from different memory access domains; Generate a triple binding parameter containing the main core number, standby core number and timestamp; Encapsulate and seal the generated triple binding parameter, and use asymmetric encryption to generate an irreversible digital envelope; Write the generated digital envelope into the task control block, and attach a uniqueness verification code based on hardware random numbers and register it to the scheduler kernel module; Establish an association mapping between the binding parameter and the task ID in the scheduler kernel module to ensure validity only within the task life cycle.

5. The dynamic CPU scheduling method based on CPU busy degree according to claim 4, wherein When it is detected that the busyness metric of the target CPU core exceeds the second dynamic overload threshold, which is 95% of the first dynamic overload value, for N consecutive cycles, perform the following steps: Generate a core overload event and trigger the process of regenerating the triple binding parameter; Add standby core numbers again from different memory access domains; Give priority to using the standby core to execute when the task starts.

6. The dynamic CPU scheduling method based on CPU busy degree according to claim 4, wherein, Execute the allocation logic according to the task attributes of each task, and submit the task to the run queue of the target CPU core for waiting to execute, including: Determine the maximum allowable length of the run queue according to the real-time processing rate of the main core of the target CPU core obtained and the estimated execution time of the task; If the load of the run queue reaches the preset load threshold, automatically redirect the task to the buffer queue of the standby core of the target CPU core; If the load of the run queue does not reach the preset load threshold, calculate the sorting score based on the priority correction value, multi-dimensional resource vector in the task attributes of each task, and the waiting time of the target CPU core; Perform verification of the digital signature validity and binding timeliness before the task enters the queue, freeze and isolate the tasks that fail the verification, trigger the regeneration of the allocation attributes, and retain the original task context data; After submitting the tasks to the run queue of the target CPU core according to the sorting score, periodically scan the queue status.

7. The dynamic CPU scheduling method based on CPU busyness according to any one of claims 1-6, characterized in that When the single execution duration of the task on the target CPU core reaches the preset threshold or is terminated by an external interrupt, re-insert the corresponding task into the run queue to trigger a new round of scheduling, including: Real-time monitor the running state of the task on the target CPU core, and capture the actual execution duration through the hardware performance counter; When it is detected that the actual execution duration exceeds the preset threshold or an external interrupt signal is received, an abnormal termination event identifier is generated, the task execution is paused, and the context snapshot saving including register status, memory page table, and cache line information is triggered; Mark the abnormal termination type code in the task control block and associate the snapshot data of the target CPU core load at the moment when the event occurs; Select the enqueue strategy for the task with the abnormal termination event identifier according to the real-time queue load status of the current target core: If the load of the main core queue of the target CPU core is lower than the preset light load threshold, it is preferentially inserted into the head of the original queue; If the main core queue of the target CPU core is higher than the preset heavy load threshold, it is diverted to the buffer queue of the standby core of the target CPU core.

8. A dynamic CPU scheduling system based on the CPU busy degree, characterized in that Including: A busy degree calculation module for monitoring the operation status parameters of each CPU core and dynamically generating the busy degree indicators of each CPU core; An attribute assignment module for parsing the business logic to be executed into a task set and assigning immutable task attributes to the tasks in the task set; A static association module for determining the respective target CPU cores based on the busy degree indicators of all current tasks and generating binding parameters to be written into the task attributes of the corresponding tasks to form a static association relationship between the tasks and the CPU cores; An allocation execution module for executing the allocation logic according to the task attributes of each task and submitting the tasks to the run queue of the target CPU core for waiting to be executed; A rescheduling module for re-inserting the corresponding task into the run queue to trigger a new round of scheduling when the single execution duration of the task on the target CPU core reaches the preset threshold or is terminated by an external interrupt.

9. A dynamic CPU scheduling device based on the CPU busyness degree, characterized in that, Including: At least one processor; And a memory communicatively connected to the at least one processor; Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the dynamic CPU scheduling method based on CPU busy degree as described in any one of claims 1-7.

10. A computer-readable storage medium having computer-executable instructions stored thereon, characterized in that, When the executable instructions are executed by the processor, the dynamic CPU scheduling method based on CPU busy degree as described in any one of claims 1-7 is implemented.

Images