Dynamic heterogeneous computing resource scheduling and distribution system for command and control software

Abstract

The application discloses a dynamic heterogeneous computing resource scheduling and distribution system for command and control software, and relates to the technical field of heterogeneous computing resource management. The dynamic graph module is used for constructing a dynamic task graph version according to a task node and a dependent edge and generating an affected subgraph. The budget reconstruction module is used for reconstructing a current critical path and a stage time budget based on the affected subgraph. The state mapping module is used for establishing a mapping relationship between the stage time budget and a heterogeneous computing resource action. The difference identification module is used for generating a resource action difference set. The action control module is used for controlling resource action submission and revocation according to the stage time budget and a resource release time. The feedback rollback module is used for correcting the stage time budget according to task execution feedback and performing rollback on an unsubmitted resource action.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous computing resource management technology, specifically to a dynamic heterogeneous computing resource scheduling and allocation system for command and control software. Background Technology

[0002] As command and control software evolves towards distributed, intelligent, and real-time collaborative architectures, its task processing is gradually shifting from a relatively fixed serial flow to a dynamic task graph with branching, merging, and conditional triggering relationships. Simultaneously, heterogeneous computing environments comprised of CPUs, GPUs, FPGAs, and other dedicated processing units are being applied. Different tasks exhibit variations in execution time, resource utilization, and switching overhead across different computing resources. To meet the end-to-end time constraints of task chains, relevant scheduling techniques typically map tasks to computing resources based on task dependencies, task priorities, resource availability, and estimated execution time, and then re-allocate resources upon task arrival, changes in dependencies, or alterations in resource status.

[0003] Existing dynamic task scheduling schemes typically focus on recalculating priorities, critical paths, or resource allocation results based on updated task dependencies when the task graph changes. However, there is a time gap between the new scheduling results generated at the logical layer and the actual release, binding, and switching of heterogeneous computing resources such as GPUs and FPGAs; the two processes are not synchronized. When task nodes are added, exited, conditional branches are removed, or dependencies change, if the recalculated resource allocation results are directly applied to physical resources, previously incomplete resource requests, bindings, and migrations may become invalid as the task graph changes again, resulting in duplicate requests, premature releases, and repeated migrations. On the other hand, while some scheduling methods consider task deadlines or path delays, they primarily use time constraints as the basis for task sorting or resource selection, lacking a control process that further decomposes the end-to-end remaining time into task node stage time budgets and determines the timing of resource action submissions based on the stage time budgets and the actual resource release time. Furthermore, for scheduling actions that have been generated but have not yet formed actual physical resource bindings, there is a lack of difference identification and rollback mechanisms to accommodate further changes in the task graph. Therefore, in runtime environments where task dependencies change frequently, the frequency of logical scheduling changes can easily exceed the speed of physical resource switching. This causes resource bindings that could have been maintained to be repeatedly altered, increasing the time consumed by resource switching and impacting task chain timelines. The aforementioned issues correspond to the technical approach of this solution, which controls these problems through affected subgraphs, stage time budgets, resource action differences, and resource action commit and rollback. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by this invention is that existing dynamic heterogeneous computing resource scheduling methods are prone to unnecessary resource reallocation and repeated resource actions when local changes occur in the dynamic task graph. There is a lack of coordination between the logical scheduling results and the actual release, binding, and switching process of heterogeneous computing resources, which can easily lead to resource migration and release oscillations. End-to-end time constraints are difficult to further implement into the time budget of task node stages and the actual submission time of resource actions. The problem is how to control the submission, cancellation, and rollback of heterogeneous computing resource actions based on stage time budgets, differences in resource actions, and resource release times when the dynamic task graph is constantly changing, so as to reduce invalid resource switching and maintain the continuity of resource scheduling under the time constraints of the task chain.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a dynamic heterogeneous computing resource scheduling and allocation system for command and control software, comprising a dynamic graph module, a budget reconstruction module, a state mapping module, a difference identification module, an action control module, and a feedback rollback module; the dynamic graph module is used to construct a dynamic task graph version and generate an affected subgraph based on task nodes and dependency edges; the budget reconstruction module is used to reconstruct the current critical path and stage time budget based on the affected subgraph; the state mapping module is used to establish a mapping relationship between the stage time budget and heterogeneous computing resource actions; the difference identification module is used to generate a resource action difference set based on the critical path, stage time budget, and resource binding relationship; the action control module is used to control the submission and cancellation of resource actions based on the stage time budget and resource release time; the feedback rollback module is used to correct the stage time budget based on task execution feedback and roll back unsubmitted resource actions.

[0007] As a preferred embodiment of the dynamic heterogeneous computing power resource scheduling and allocation system for command and control software described in this invention, the step of constructing a dynamic task graph version and generating an affected subgraph includes: establishing a dynamic task graph version according to the dependency relationships between task nodes; writing task node identifiers, execution statuses, and resource binding relationships into the corresponding task nodes; and establishing dependency edges between two task nodes with dependency relationships; when the set of task nodes and the set of dependency edges change, saving the dynamic task graph version before the change, and generating a new dynamic task graph version based on the changed set of task nodes and the set of dependency edges; comparing the task node identifiers and dependency edge endpoint combinations in the two dynamic task graph versions before and after the change to determine the change locations where additions, deletions, branch unblocking, and path merging occur; extending upstream and downstream from the change location along the dependency edges to the boundary nodes where the connection relationships have not changed; forming an affected subgraph from the task nodes and dependency edges within the extended range; and writing the affected subgraph into the new dynamic task graph version.

[0008] As a preferred embodiment of the dynamic heterogeneous computing resource scheduling and allocation system for command and control software described in this invention, the reconstructing of the current critical path and stage time budget includes: traversing from the entry task node of the affected subgraph along the dependency edges to the exit task node to form candidate dependency paths containing the affected subgraph; reading the remaining execution time of each task node in the candidate dependency path, accumulating the corresponding remaining execution time according to the order of the task nodes in the candidate dependency path to obtain the remaining path time of each candidate dependency path; subtracting the corresponding remaining path time from the time length between the end-to-end completion time of the task chain and the current time to obtain the path time margin of each candidate dependency path, and determining the candidate dependency path with the smallest path time margin as the current critical path; and dividing the remaining available time according to the proportion of remaining execution time of the unfinished task nodes in the current critical path to generate the stage time budget corresponding to each unfinished task node.

[0009] As a preferred embodiment of the dynamic heterogeneous computing resource scheduling and allocation system for command and control software described in this invention, the following steps are included: establishing the mapping relationship between stage time budgets and heterogeneous computing resource actions: configuring candidate states, pending submission states, submitted states, and pending cancellation states for each stage time budget; establishing a budget association between the stage time budget and the corresponding task node; reading the executable heterogeneous computing resources of the corresponding task node and the task execution time corresponding to each heterogeneous computing resource; combining the available time of each heterogeneous computing resource to obtain the expected completion time of the task node on each heterogeneous computing resource; retaining heterogeneous computing resources whose expected completion time is not later than the end time of the corresponding stage time budget; and determining the target heterogeneous computing resource from the retained results.

[0010] As a preferred embodiment of the dynamic heterogeneous computing power resource scheduling and allocation system for command and control software described in this invention, the step of establishing the mapping relationship between the phase time budget and the heterogeneous computing power resource action further includes comparing the current resource binding of the task node with the target heterogeneous computing power resource to form a corresponding heterogeneous computing power resource action; using the task node identifier as the association key, writing the corresponding phase time budget, budget status and heterogeneous computing power resource action into the same task scheduling association record.

[0011] As a preferred embodiment of the dynamic heterogeneous computing power resource scheduling and allocation system for command and control software described in this invention, the process of generating the resource action difference set includes: reading the critical path, stage time budget, and resource binding relationship before and after the task graph change to form a resource action set before the change and a resource action set after the change; pairing the resource action set before the change and the resource action set after the change according to the task node identifier; when the target heterogeneous computing power resources after pairing are the same, writing the corresponding resource action into the hold action set; when the task node corresponding to the resource action before the change does not exist in the resource action set after the change, writing the corresponding resource action into the action set to be cancelled; when the task node corresponding to the resource action after the change does not exist in the resource action set before the change, writing the corresponding resource action into the action set to be submitted.

[0012] As a preferred embodiment of the dynamic heterogeneous computing power resource scheduling and allocation system for command and control software described in this invention, the process of generating the resource action difference set further includes, when the paired task nodes are the same and the target heterogeneous computing power resources are different, establishing a migration correspondence between the resource actions before the change and the resource actions after the change, and forming a resource action difference set composed of the set of actions to be maintained, the set of actions to be undone, the set of actions to be submitted, and the migration correspondence.

[0013] As a preferred embodiment of the dynamic heterogeneous computing resource scheduling and allocation system for command and control software described in this invention, the submission and cancellation of control resource actions includes: reading the end time of the stage time budget corresponding to the action to be submitted, the remaining execution time of the corresponding task node on the target heterogeneous computing resource, and the resource switching time; subtracting the remaining execution time and resource switching time from the end time of the stage time budget to obtain the latest resource acquisition time for the critical task; reading the remaining occupation time of the currently executing task on the target heterogeneous computing resource, and obtaining the resource release time based on the current time and the remaining occupation time; comparing the latest resource acquisition time of the critical task with the resource... When the resource release time is no later than the latest resource acquisition time of the critical task, the current resource is bound to the resource release time, and the corresponding action to be submitted is submitted after the resource release. When the resource release time is later than the latest resource acquisition time of the critical task, the current target heterogeneous computing power resource is canceled as the target of the action to be submitted, and the heterogeneous computing power resource that meets the stage time budget is re-determined. For actions to be revoked, the corresponding heterogeneous computing power resource action is revoked before the corresponding heterogeneous computing power resource action has formed an actual resource binding. When the corresponding heterogeneous computing power resource action has formed an actual resource binding, the current resource is bound to the resource release time and then the resource is released.

[0014] As a preferred embodiment of the dynamic heterogeneous computing resource scheduling and allocation system for command and control software described in this invention, the correction phase time budget includes: collecting the actual completion time of task nodes, comparing the actual completion time with the end time of the corresponding phase time budget to obtain the time deviation; when the actual completion time is earlier than the end time of the corresponding phase time budget, increasing the time deviation to the remaining available time of the unfinished task nodes following the current critical path; when the actual completion time is later than the end time of the corresponding phase time budget, deducting the time deviation from the remaining available time of the unfinished task nodes following the current critical path, and writing back the corresponding phase time budget based on the updated remaining available time.

[0015] As a preferred embodiment of the dynamic heterogeneous computing resource scheduling and allocation system for command and control software described in this invention, the rollback of unsubmitted resource actions includes: when the dynamic task graph version changes again, reading the budget status of the corresponding stage time budget, rolling back the stage time budget in the candidate state and the stage time budget in the pending state where the corresponding heterogeneous computing resource actions have not yet formed actual resource bindings, and canceling the corresponding heterogeneous computing resource actions that have not formed actual resource bindings; retaining the current resource bindings for heterogeneous computing resource actions that have formed actual resource bindings, and writing the latest task execution feedback into a new scheduling loop.

[0016] The beneficial effects of this invention are as follows: The dynamic heterogeneous computing power resource scheduling and allocation system for command and control software provided by this invention identifies the differences in resource scheduling results generated by the dynamic task graph before and after, and transforms task topology changes into incremental resource actions such as hold, pending submission, pending cancellation, and migration. This allows tasks that have not changed their target resources to continue to maintain their existing scheduling state, reducing repeated resource requests and releases caused by local task changes. By further converting the end time of the stage budget into the latest resource acquisition time of the critical task and comparing it with the actual release time of heterogeneous computing power resources, resource actions are only triggered to switch or reselect when continuing to wait would exceed the task time boundary, reducing unnecessary preemption and migration. By distinguishing between resource actions that have not yet formed actual physical binding and resource states that have already formed binding, when the dynamic graph changes again, actions that have not yet been implemented are cancelled, and the already formed resource binding is used as the new scheduling state. This avoids frequent changes in logical scheduling directly driving repeated switching of physical resources, and maintains a relatively consistent time relationship between dynamic task graph changes, task time constraints, and the actual switching process of heterogeneous computing power resources. Attached Figure Description

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

[0018] Figure 1 The overall flowchart of the dynamic heterogeneous computing power resource scheduling and allocation system for command and control software provided by the present invention is shown.

[0019] Figure 2 This invention provides a resource action control diagram for a dynamic heterogeneous computing power resource scheduling and allocation system for command and control software. Detailed Implementation

[0020] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0021] Reference Figure 1-2 As one embodiment of the present invention, a dynamic heterogeneous computing resource scheduling and allocation system for command and control software is provided, comprising: Dynamic graph module, budget reconstruction module, state mapping module, difference recognition module, action control module, feedback rollback module; The dynamic graph module is used to build a dynamic version of the task graph based on task nodes and dependency edges and generate affected subgraphs.

[0022] Furthermore, constructing a dynamic task graph version and generating an affected subgraph includes: establishing a dynamic task graph version according to the dependencies between task nodes; writing task node identifiers, execution statuses, and resource binding relationships into the corresponding task nodes; and establishing dependency edges between two task nodes with dependencies. When the set of task nodes and the set of dependency edges change, the dynamic task graph version before the change is saved, and a new dynamic task graph version is generated based on the changed set of task nodes and the set of dependency edges. The task node identifiers and dependency edge endpoint combinations in the two dynamic task graph versions are compared to determine the change locations where additions, deletions, branch unwinding, and path merging have occurred. From the change location, the process extends upstream and downstream along the dependency edges to the boundary nodes where the connection relationships have not changed. The task nodes and dependency edges within the extended range form an affected subgraph, and the affected subgraph is written into the new dynamic task graph version.

[0023] It should be noted that one approach to constructing a dynamic task graph version and generating affected subgraphs specifically includes the dynamic graph module receiving task node information and task dependency information output by the runtime scheduler of the command and control software. The task node information includes at least a task node identifier, execution status, and resource binding relationships. The task node identifier corresponds to a unique task number assigned by the runtime scheduler of the command and control software; the execution status corresponds to the task's running status in the scheduling queue; and the resource binding relationship corresponds to the identifier of the heterogeneous computing resources currently occupied by the task.

[0024] This embodiment represents the execution status numerically as follows: , Indicates the task node index. Indicates pending execution. Indicates that it is being executed. This indicates that the execution is complete. This indicates that the current task chain has been exited. Resource binding relationships are represented as follows: , This indicates that the task node has not yet been bound to heterogeneous computing resources. This indicates that the current bound index of the task node is heterogeneous computing resources This represents the index of heterogeneous computing resources.

[0025] The dynamic graph module is numbered by version. Identify the current dynamic task graph version The dynamic task graph version consists of a set of task nodes. and Dependency Edge Set Composition. Task Nodes At least associate task node identifier and execution status and resource binding relationships When the task node The startup requires waiting for the task node. When outputting, a connection is established between the two task nodes. point to Dependency edges , Indicates from task node Point to task node Dependency edges, This represents the index of another task node, and the dependent edge directly reads the task predecessor relationship maintained by the scheduler during the runtime of the command and control software.

[0026] In this embodiment, the dynamic task graph version is a directed acyclic graph formed by the sequential dependencies of tasks. The task scheduler only writes the dependency edges that do not form a closed loop into the corresponding dynamic task graph version to ensure that a task dependency path with a definite entry and exit can be formed along the dependency edges.

[0027] For task nodes with conditional triggering relationships, when the conditional result has not yet been generated, the corresponding candidate branch edge is retained in the current dynamic task graph version and marked as waiting; after the conditional result is generated, only the actually triggered dependency edge is retained as a valid dependency edge, and the untriggered dependency edge is removed from the set of valid dependency edges in the next dynamic task graph version.

[0028] Once the triggering result is clear, the graph structure change where the dependent edge corresponding to the unselected branch is removed from the set of valid dependent edges is defined as branch decomposition. For two or more task nodes that were originally on different dependency paths, when these task nodes have a common successor task node in the new dynamic task graph version, the graph structure change resulting in a common successor task node is defined as path merging. Branch decomposition is mainly manifested as the removal of the corresponding dependent edge from the set of valid dependent edges, while path merging is mainly manifested as a change in the endpoint combination of the corresponding dependent edges on different dependency paths. Therefore, both types of graph structure changes can be identified through the task node set and dependent edge set in the two versions of the dynamic task graph.

[0029] When the runtime scheduler reports any of the following events: task node creation, task node exit, or change in task dependencies, the dynamic graph module retains the dynamic task graph version before the change. Then generate based on the latest set of task nodes and the latest set of dependency edges. .

[0030] The dynamic graph module compares the task node sets and dependency edge sets of the two dynamic task graph versions. For the task node set, task nodes that exist only in one version are identified as newly added or deleted task nodes; for the dependency edge set, dependency edges that exist only in one version are identified as newly added or deleted dependency edges. For task nodes whose node identifiers exist in both versions but whose dependency edge endpoint combinations change, the corresponding task node is added to the changed position set.

[0031] Considering that local structural changes in the task graph do not necessarily require the entire task graph to re-participate in scheduling, the dynamic graph module extends upstream and downstream along the dependency edges from each changed position. For a task node that exists in two versions of the dynamic task graph, the predecessor and successor task node sets of the corresponding task node in each version are read respectively.

[0032] If the sets of predecessor task nodes are the same in the previous and subsequent versions, and the sets of successor task nodes are the same, the corresponding task node is identified as a boundary node, and the expansion along the direction passing through the corresponding boundary node is stopped; if at least one of the sets of predecessor task nodes and successor task nodes changes, the corresponding task node is included in the expansion range and the adjacent dependent edges are traversed.

[0033] When the expanded ranges resulting from multiple changes overlap, the overlapping task nodes and dependent edges are merged to form a unique affected subgraph. For tasks that have already moved from... Delete but For task nodes that already exist in the subgraph, the corresponding task node will no longer be used as an executable node in the new task path. Only the task node identifier and the resource binding relationship before the change will be retained in the change record of the affected subgraph.

[0034] After the affected subgraph is formed, the scope of task nodes and the scope of dependent edges corresponding to the affected subgraph are written into the new dynamic task graph version. The scheduling data is used to generate a new version of the dynamic task graph. And the corresponding affected subgraph; task nodes that have not entered the affected subgraph maintain their existing execution state and resource binding relationship.

[0035] The budget refactoring module is used to refactor the current critical path and stage time budgets based on the affected subgraphs.

[0036] Furthermore, reconstructing the current critical path and stage time budget includes: traversing from the entry task node of the affected subgraph along the dependency edges to the exit task node to form candidate dependency paths containing the affected subgraph; reading the remaining execution time of each task node in the candidate dependency path, accumulating the corresponding remaining execution time according to the order of the task nodes in the candidate dependency path to obtain the remaining path time of each candidate dependency path; subtracting the corresponding remaining path time from the time between the end-to-end completion time of the task chain and the current time to obtain the path time margin of each candidate dependency path, and determining the candidate dependency path with the smallest path time margin as the current critical path; and dividing the remaining available time according to the proportion of remaining execution time of the unfinished task nodes in the current critical path to generate the stage time budget corresponding to each unfinished task node.

[0037] It should be noted that one specific approach to refactoring the current critical path and phase time budget includes the budget refactoring module receiving a dynamic task graph version. And the affected subgraph, while reading the current scheduling time. End-to-end completion time of the current task chain And the remaining execution time for each task node.

[0038] End-to-end completion time The current command and control task chain is defined by an absolute time value provided by the real-time task configuration at the time of its creation. This time value remains unchanged within a single scheduling cycle for the same task chain. Read the system monotonic clock directly.

[0039] To obtain the remaining execution time of a task node, this embodiment records the execution time of the corresponding task program and executable heterogeneous computing resources for maintaining the task resources of the task node. For task nodes... The corresponding task program is at index 1 The effective execution records already formed on the heterogeneous computing resources are used to calculate the actual execution duration by subtracting the corresponding actual start time from the actual completion time of each execution. The total effective execution durations are then summed and divided by the number of effective executions. Obtain task nodes The corresponding task program in heterogeneous computing resources Average task execution time .

[0040] When there is no historical execution record, The initial value is obtained by performing a baseline run on the corresponding task program and the corresponding heterogeneous computing resources during the system deployment phase.

[0041] For a task node that has already started execution, read the completed workload and total workload recorded during the execution of the corresponding task program, and divide the completed workload by the total workload to obtain the execution progress. The value ranges from 0 to 1. Task nodes without subdivided workload counts are treated as a single, indivisible scheduling segment as a unit of workload, and will be counted until the current scheduling segment is completed. Set it to 0.

[0042] Task Node In heterogeneous computing resources Remaining execution time Based on average task execution time Ratio of unfinished work The product is obtained. The task nodes that have not yet started execution correspond to... The corresponding task nodes that have been completed .

[0043] For task nodes that are already bound to heterogeneous computing resources, read the corresponding resource bindings. The remaining execution time of the corresponding task node For task nodes that are not yet bound to heterogeneous computing resources, all executable heterogeneous computing resources corresponding to them... Select the smallest value as the remaining execution time of the current task node. .

[0044] When an affected subgraph entry task node has upstream dependent task nodes that have not yet been completed, the remaining execution time of the corresponding upstream dependent task nodes is included in the waiting time from the current scheduling time until the affected subgraph entry task node can start execution, and is deducted when calculating the time slack of candidate dependent paths; when all upstream dependent task nodes of the affected subgraph entry task node have been completed, the corresponding waiting time is set to 0.

[0045] The budget refactoring module starts from the entry task node of the affected subgraph, traverses along the valid dependency edges in the updated dynamic task graph version to the corresponding task chain exit task node, and compiles a candidate dependency path set of all paths that pass through the affected subgraph and maintain valid dependencies. The execution status is... The task node will no longer participate in the accumulation of remaining path time.

[0046] When the candidate dependency path set is empty, the current critical path and stage time budget for the corresponding affected range are not generated, and the resource action results for the corresponding affected range in the new scheduling version are set to empty, and the path time calculation for the corresponding affected range is stopped.

[0047] For each candidate dependency path According to the order in the path, calculate the remaining execution time of all unfinished task nodes. Add them together to get the remaining path time of the candidate dependency paths. Then use the end-to-end completion time. With the current scheduling time Subtract the corresponding time length between This gives the time margin that each candidate dependency path can reserve for resource waiting and resource switching.

[0048] To prioritize budget refactoring for the path that truly constrains the end-to-end completion time after the dynamic graph changes, this embodiment identifies the candidate dependency path with the smallest time slack as the current critical path, represented as:

[0049] in, Indicates the current critical path, Represents the set of candidate dependency paths. Indicates the end-to-end completion time of the task chain. Indicates the current scheduling time. Indicates candidate dependency paths The remaining path time. This relationship directly couples the remaining computational load of the task-dependent paths with the remaining end-to-end time, avoiding the need to determine the critical path solely based on path length.

[0050] When two or more candidate dependency paths have the same minimum time slack, they are selected from largest to smallest according to the number of unfinished task nodes in the path; if they are still the same, they are selected from smallest to largest according to the path entry task node identifier.

[0051] When the current critical path If there are no unfinished task nodes, the phase time budget allocation will no longer be executed, and the budget refactoring of the corresponding affected scope will be stopped.

[0052] If there are incomplete task nodes in the current critical path, then and The time interval between these intervals is recorded as the remaining available time for the current critical path. Each unfinished task node is allocated its remaining execution time as a proportion of the total remaining execution time of all unfinished task nodes on the current critical path. , is represented as:

[0053] in, Indicates the task nodes in the current critical path. The duration of the phased budget, Represents task node The remaining execution time, The current critical path is represented sequentially during the summation process. In the context of task nodes whose execution status is not equal to 2, this relationship allows nodes with longer remaining execution times to receive a larger share of stage time, while ensuring that the total stage budget does not exceed the remaining available time of the current critical path.

[0054] when At that time, and The time interval between these intervals is used as the remaining available time for the current critical path. ;when At that time, the remaining available time of the current critical path will be... Set it to 0 so that the end time of the corresponding stage budget is not earlier than the current scheduling time.

[0055] To represent the stage budget as an absolute time boundary that can be directly compared with the actual task completion time, the timeline is calculated from the current scheduling time to the task node in the current critical path. The budget durations for each stage are summed sequentially to obtain the task nodes. The end time of the stage budget is denoted as:

[0056] in, Represents task node At the end of the phase budget, Represents task node Task node located on the current critical path Previously or related to task nodes same, Represents task node The phase budget duration. In this embodiment, the phase time budget includes at least the phase budget duration. and the end time of the phase budget When the remaining time on the current critical path is already greater than... and Even when the time interval is between, a stage time budget is still generated.

[0057] The state mapping module is used to establish the mapping relationship between stage time budgets and heterogeneous computing resource actions.

[0058] Furthermore, establishing the mapping relationship between stage time budgets and heterogeneous computing resource actions includes configuring candidate states, pending submission states, submitted states, and pending cancellation states for each stage time budget, and establishing a budget association between the stage time budget and the corresponding task node; reading the executable heterogeneous computing resources of the corresponding task node and the task execution time corresponding to each heterogeneous computing resource, and combining the available time of each heterogeneous computing resource to obtain the expected completion time of the task node on each heterogeneous computing resource; retaining heterogeneous computing resources whose expected completion time is no later than the end time of the corresponding stage time budget, and determining the target heterogeneous computing resource from the retained results; comparing the current resource binding of the task node with the target heterogeneous computing resource to form the corresponding heterogeneous computing resource action; and using the task node identifier as the association key, writing the corresponding stage time budget, budget status, and heterogeneous computing resource action into the same task scheduling association record.

[0059] It should be noted that one scheme for establishing the mapping relationship between stage time budget and heterogeneous computing resource actions specifically includes the state mapping module receiving the current critical path, stage time budget, and remaining execution time of task nodes, while reading the resource availability time maintained by the heterogeneous computing resource manager.

[0060] Available moments of heterogeneous computing resources are denoted as When the corresponding heterogeneous computing resources are in an idle state, Take as the current scheduling time When heterogeneous computing resources are executing tasks, the estimated release time of the currently executing task recorded by the resource scheduler will be used as the reference time. .

[0061] This embodiment configures the budget status for each stage of the time budget. . This indicates a candidate state, meaning that the phase time budget has been generated but no resource actions have yet been generated to be executed; This indicates a pending submission status, meaning that the target heterogeneous computing power resource action has been formed but the corresponding physical resource binding has not yet been completed; This indicates a submitted status, meaning the corresponding heterogeneous computing resource action has been actually completed and a corresponding physical resource binding has been formed; This indicates a pending cancellation status, meaning that the time budget for the corresponding stage no longer belongs to the current scheduling result, but the corresponding resource action has not yet been cancelled.

[0062] The budget status of newly generated stage time budgets is set to candidate status. For stage time budgets where the task nodes, stage time budgets, and target heterogeneous computing resource indexes remain unchanged in both the old and new dynamic task graph versions, the existing budget status is retained.

[0063] The state mapping module reads the task node. The corresponding set of executable heterogeneous computing resources The corresponding set is obtained from the task program deployment configuration and only includes heterogeneous computing resources that have the corresponding runtime environment installed and can execute the corresponding task program on the task node.

[0064] for Each heterogeneous computing resource The corresponding resource availability time With task nodes In heterogeneous computing resources Remaining execution time Add them together to get the estimated completion time of the task node on the corresponding resource. .

[0065] Comparing one by one and task nodes End of phase budget Retain heterogeneous computing resources whose expected completion time is no later than the end time of the stage budget to form a set of heterogeneous computing resources that meet the time constraints. .

[0066] Current resource binding The corresponding heterogeneous computing resource index belongs to the set of heterogeneous computing resource indexes that meet the time constraints. At that time, the corresponding heterogeneous computing resource index bound to the current resource will be further determined as the target heterogeneous computing resource index. When the current resource is bound The corresponding heterogeneous computing resource index does not belong to At that time, compare them from morning to night according to the expected completion time. The heterogeneous computing resources corresponding to each resource index are selected, and the index corresponding to the heterogeneous computing resource with the earliest expected completion time is determined as the target heterogeneous computing resource index. When two or more heterogeneous computing resources have the same expected completion time, the index of the heterogeneous computing resource with the smallest value is determined as the [index of the resource]. .

[0067] when When empty, from the set of executable heterogeneous computing resources Select the heterogeneous computing power resource with the earliest expected completion time as the temporary target heterogeneous computing power resource, and keep the corresponding stage time budget as a candidate.

[0068] Identify target heterogeneous computing resources Then, the target heterogeneous computing resources are bound to the current resources. Comparison. When both are the same, a resource-preserving action is formed; when... And a resource binding action is formed when the target heterogeneous computing power resources are not zero; when A resource switching action is initiated when the value is not zero and the resource is not the target heterogeneous computing resource. All heterogeneous computing resource actions record the task node identifier, the resource identifier before the change, and the target resource identifier.

[0069] To clarify the mapping relationship between the stage time budget and heterogeneous computing resource actions, this embodiment establishes a task scheduling association record using the task node identifier as the association key. The task scheduling association record includes at least the task node identifier and the stage budget duration. End time of phase budget Budget status Current resource binding Target heterogeneous computing resources, heterogeneous computing resource actions, and resource action execution flags. .

[0070] This indicates that the corresponding heterogeneous computing resource actions have not yet formed an actual physical resource binding. This indicates that the resource controller has returned confirmation that the target heterogeneous computing power resource binding is complete, and the corresponding heterogeneous computing power resource action has been actually executed. The newly generated task scheduling association record... Initially 0.

[0071] Newly generated task scheduling association records that require changes to resource bindings remain in the candidate state, and the current resource bindings do not change during the state mapping process. The state mapping module outputs the corresponding set of task scheduling association records.

[0072] The difference identification module is used to generate a set of resource action differences based on the critical path, stage time budget, and resource binding relationships.

[0073] Furthermore, the process of generating the resource action difference set includes: reading the critical path, stage time budget, and resource binding relationship before and after the task graph change to form a resource action set before the change and a resource action set after the change; pairing the resource action set before the change and the resource action set after the change according to the task node identifier; when the target heterogeneous computing power resources after pairing are the same, writing the corresponding resource action into the hold action set; when the task node corresponding to the resource action before the change does not exist in the resource action set after the change, writing the corresponding resource action into the action to be undone set; when the task node corresponding to the resource action after the change does not exist in the resource action set before the change, writing the corresponding resource action into the action to be committed set; when the task nodes after pairing are the same and the target heterogeneous computing power resources are different, establishing a migration correspondence between the resource actions before the change and the resource actions after the change, and forming a resource action difference set by the hold action set, the action to be undone set, the action to be committed set, and the migration correspondence.

[0074] It should be noted that one specific approach to generating the resource action difference set involves establishing a mapping between the stage time budget and the target heterogeneous computing resources. After this mapping, the new scheduling results can reflect the resource requirements of each task node in the current task graph. However, local changes in the dynamic task graph do not necessarily mean that all original resource allocations are invalid. If the new resource mapping directly overwrites the original results, unchanged resource bindings will be processed repeatedly. Therefore, it is necessary to further compare the resource actions before and after the change, extracting only the truly changed parts, so that task graph changes are converted into incremental resource actions such as hold, undo, commit, and migrate, and then control actual resource changes accordingly.

[0075] The difference recognition module reads the task scheduling association records corresponding to the dynamic task graph version before the change and the task scheduling association records corresponding to the dynamic task graph version after the change.

[0076] For the pre-change dynamic task graph version, the task node identifier, current resource binding, and target heterogeneous computing resources are read from the task scheduling association record to form the pre-change resource action set. For the post-change dynamic task graph version, the same fields are used to form the post-change resource action set. When the corresponding affected area has not generated the current critical path and stage time budget, no new resource action record is written to the post-change resource action set for the corresponding affected area.

[0077] A single resource action record is identified by the task node identifier and the current resource binding at the time the resource action is formed. And the target heterogeneous computing resources are composed of the same task node identifier. Only one valid resource action record is retained in the same dynamic task graph version.

[0078] When the dynamic task graph version changes, the dependencies, stage time budgets, and target heterogeneous computing resources of task nodes do not change synchronously. Some task nodes, although in the new task graph version, still have the same target heterogeneous computing resources as before the change. Some resource actions may also be in different execution stages, either awaiting submission or already having formed actual resource bindings. If the changed resource mapping result directly replaces the previous resource action, the state of resource actions not yet completed in the previous scheduling cycle will be reinitialized, causing task nodes whose target resources have not changed to re-form the same resource request, or causing existing resource bindings to be reprocessed. Therefore, before generating new physical resource actions, the target heterogeneous computing resources, budget status, and resource action execution flags corresponding to the previous resource action are retained, and the resource actions of the two versions are compared using the task node identifier.

[0079] The difference identification uses the task node identifier as a fixed association object, pairs the same task node in the resource action set before the change and the resource action set after the change, and generates resource action differences according to four determination rules.

[0080] First, when the same task node exists in both resource action sets, and the target heterogeneous computing resources before and after the change are the same, the corresponding resource action after the change is written into the retention action set.

[0081] The changed task scheduling association record inherits the budget status of the task scheduling association record before the change. and resource action execution flags The inherited budget status is pending submission. At that time, the same resource action will not be regenerated, and the corresponding task scheduling association record will continue to be output to the action control module, according to the changed stage budget end time. The latest time to regain critical mission resources; the inherited budget status is committed and At the same time, maintain the existing resource bindings.

[0082] Second, when the task node identifier exists only in the resource action set before the change but not in the resource action set after the change, the corresponding resource action before the change is written into the action set to be undone, and the budget status of the corresponding task scheduling association record is updated to the undone status.

[0083] Third, when the task node identifier exists only in the changed resource action set but not in the original resource action set, the corresponding changed resource action is written into the pending action set, and the budget status of the corresponding task scheduling associated record is updated from the candidate status to the pending status.

[0084] Fourth, when the same task node exists in both the pre-change and post-change resource action sets, but the target heterogeneous computing resources before and after the change are different, a migration correspondence is established between the pre-change and post-change resource actions of the same task node, and the post-change task scheduling association record is set to a pending submission status. At this time, the pre-change resource binding is still retained as the current physical resource state.

[0085] The resource action difference set consists of the hold action set, the action set to be undone set, the action set to be committed set, and migration correspondences. The difference identification module outputs the resource action difference set and the task scheduling association record that has completed budget status updates.

[0086] Maintaining the action does not require the phase time budget before and after the change to completely stop updating. Instead, it inherits the existing resource action state while keeping the target heterogeneous computing power resources unchanged, so that the new phase budget can continue to constrain the resource actions that have not yet been completed, without having to re-initiate the corresponding physical resource application.

[0087] Through the above difference identification process, changes in the task graph structure are transformed into incremental resource actions that need to be changed in actual heterogeneous computing resources. Task nodes that have not undergone target resource changes will not generate the same resource request and resource release actions repeatedly.

[0088] It should also be noted that by comparing the task nodes and target heterogeneous computing resources in the task scheduling association records before and after the change, resource actions are divided into maintain, pending cancellation, pending submission, and migration relationships. Essentially, this changes the process of "reforming a complete resource allocation scheme" to "only extracting resource actions that have truly changed between the two scheduling results." If the target resource of the same task node remains unchanged in the previous and current versions, it inherits the original budget state and resource action execution flag. Actions that existed in the original version but not in the new version enter the pending cancellation range, while actions added in the new version enter the pending submission range. Migration relationships are only established when the target resource of the same task node changes. When the dynamic task graph changes frequently, directly overwriting existing resource allocations each time can easily lead to the duplicate generation of resource requests that have already been generated but not yet executed, and may also cause unchanging resource bindings to undergo meaningless release and re-application. Through the resource action difference set, the system retains the unchanged scheduling intent, allowing only incremental changes to enter the resource control range. Actions pending submission but with unchanged target resources are not lost; instead, they continue to be judged according to the new stage budget. This compresses the frequent changes at the task graph level into the necessary incremental changes at the physical resource level, reducing the probability of repeated resource requests, releases, and migrations.

[0089] The action control module is used to control the submission and cancellation of resource actions based on the stage time budget and resource release time.

[0090] Furthermore, refer to Figure 2 The control of resource action submission and cancellation includes: reading the end time of the time budget of the corresponding stage for the action to be submitted, the remaining execution time of the corresponding task node on the target heterogeneous computing resources, and the resource switching time; subtracting the remaining execution time and resource switching time from the end time of the stage time budget to obtain the latest resource acquisition time for the critical task; reading the remaining occupation time of the currently executing task on the target heterogeneous computing resources, and obtaining the resource release time based on the current time and the remaining occupation time; comparing the latest resource acquisition time and the resource release time for the critical task; if the resource release time is not later than the latest resource acquisition time for the critical task, keeping the current resource bound to the resource release time, and submitting the corresponding action to be submitted after resource release; if the resource release time is later than the latest resource acquisition time for the critical task, canceling the current target heterogeneous computing resources as the target for the action to be submitted, and re-determining the heterogeneous computing resources that meet the stage time budget; for actions to be cancelled, cancelling the corresponding heterogeneous computing resources action before the corresponding heterogeneous computing resources action has formed an actual resource binding, and keeping the current resource bound to the resource release time after the corresponding heterogeneous computing resources action has formed an actual resource binding, and then executing the resource release.

[0091] It should be noted that one specific scheme for controlling the submission and revocation of resource actions involves the following: after the differences in resource actions are determined, the actions to be submitted cannot be immediately applied to heterogeneous computing resources. This is because the target resource may still be executing its original task, and the critical task itself may have a certain waiting margin. If a switch is made immediately upon the generation of a new resource action, it is easy to increase premature release and resource migration. Therefore, the stage budget needs to be further converted into a time boundary at which the task must acquire the target resource at the latest, and compared with the actual release time of the target resource. Based on this, it is determined whether to continue waiting, reselect resources, or submit the corresponding resource action.

[0092] The action control module receives the resource action difference set and reads the stage budget end time of the task node corresponding to the action to be submitted. Task Nodes In the target heterogeneous computing power resource index Remaining execution time on corresponding heterogeneous computing resources And the time spent switching resources.

[0093] Resource switching time depends on the same task node From current resource binding The actual historical switching records for switching to the target heterogeneous computing resources are obtained. When multiple valid switching records exist, the duration from each switch starting from the resource controller to the point where the corresponding task can be executed on the target resource is added together, and then divided by the number of valid switches to obtain the resource switching time. Current resource binding When the resource switching time is the same as the target heterogeneous computing resources, the resource switching time will be set to 0.

[0094] when At that time, resource binding will begin from the resource controller and be executed to the index. The duration between execution of corresponding tasks by heterogeneous computing resources is taken as the resource binding time, and is obtained by averaging historical data in the same way as the resource switching time. If no corresponding historical record exists, the initial value is the duration obtained by measuring the corresponding resource switching or resource binding process during the system deployment phase.

[0095] After the target heterogeneous computing resources are determined during the state mapping process, the obtained target heterogeneous computing resources only indicate that the corresponding task node has the feasibility of resource execution under the current time budget. It does not mean that the corresponding resource action needs to be executed immediately after the target resource is determined. The target heterogeneous computing resources may still be in the effective occupation phase of other tasks, and the time between the task node obtaining the target resource and completing execution includes the remaining task execution time and the resource binding or resource switching process. If the moment of target resource determination is directly used as the time of resource action submission, the resource with waiting capacity will end its original occupation prematurely; if only waiting for the target resource to be released naturally may occupy the remaining time required for the task node to complete its own execution.

[0096] The end time of the stage budget only specifies the latest completion boundary of the task. Whether heterogeneous computing resources need to be vacated in advance depends on the remaining execution time and resource switching time of the task itself. Therefore, this embodiment deducts two parts of time from the end time of the stage budget to obtain the latest time when the task must obtain the target heterogeneous computing resources, expressed as:

[0097] in, Represents task node The latest time when the critical task obtains resources. Indicates the end time of the corresponding stage budget. Represents task node Remaining execution time on the target heterogeneous computing resources This indicates the time taken to switch resources from the current resource binding to the target heterogeneous computing power resource.

[0098] Therefore, the end time of the stage budget, originally used to limit the task completion time, is transformed into a time boundary that the target heterogeneous computing resources must actually be available, allowing the task-side completion time constraint and the resource-side release status to be compared under the same absolute time benchmark. The end time of the stage budget is not directly compared with the resource release time. After reserving the remaining execution time of the task and the time consumed by resource switching, the resource waiting process will not occupy the execution time necessary for task completion.

[0099] The action control module refreshes the current execution status of the target heterogeneous computing resources. If the target heterogeneous computing resources are currently idle, the remaining occupied time will be updated. Set to 0; when there is currently an execution task on the target heterogeneous computing resource, read the remaining execution time of the current non-schedulable segment recorded by the resource scheduler as... The current scheduling time and Add them together to obtain the resource release time when the corresponding heterogeneous computing power resource can end its current occupation and accept new resource actions. .

[0100] For task nodes The target heterogeneous computing resources adopt the following core control relationship:

[0101] in, This indicates the timing of resource release for the target heterogeneous computing resources. When When established, the target heterogeneous computing resources can be released naturally before the time boundary when the task must obtain the resources at the latest. Therefore, the existing occupancy status of the target heterogeneous computing resources is maintained until the corresponding resource release time, without changing the existing resource binding in advance.

[0102] During this period, the corresponding resource actions remain in a pending state, rather than transitioning to a committed state due to the identification of the target heterogeneous computing resources. The current resource binding is only changed after the resource release event actually occurs and the target resource binding is completed. Thus, the formation of the task scheduling result is separated from the change of the physical resource state, and the waiting time allowed in the stage time budget is used to absorb the current occupation of the target resource.

[0103] When the system monotonic clock reaches Upon receiving the corresponding resource release event, a task node is sent to the resource controller. This refers to heterogeneous computing resource actions. After a resource action is sent, the budget status remains pending submission, and the resource action execution flag is displayed. The value remains at 0; once the resource controller returns confirmation that the target heterogeneous computing power resource binding is complete, the budget status will be updated to "submitted," and the resource action execution flag will be set. Updated to 1, and the current resource binding updated to... .

[0104] For example, if the phase budget of a task node ends 40 milliseconds before the current time, the remaining execution time of the task node on the target heterogeneous computing resources is 20 milliseconds, and the resource switching time is 5 milliseconds, then the latest time for the critical task to acquire resources is 15 milliseconds before the current time. If the target heterogeneous computing resources are released naturally after 8 milliseconds, the current resource occupancy will be maintained for 8 milliseconds before the corresponding resource action is sent; if the target heterogeneous computing resources can only be released after 18 milliseconds, then the resource release time is already later than the latest time for the critical task to acquire resources.

[0105] When the resource release time is later than the latest resource acquisition time of the critical task, the current target heterogeneous computing power resource is cancelled as the target of the pending actions in this round, but the task currently being executed with the corresponding resource is not released. (At the task node) Executable heterogeneous computing resource index set Exclude the current target heterogeneous computing resource index Read the resource availability time corresponding to the remaining resource index respectively. and remaining execution time of task nodes Adding the two together gives the corresponding estimated completion time. The estimated completion date should be no later than the end date of the phase budget. The resource indexes are used to select the resource index with the earliest expected completion time as the new target heterogeneous computing power resource index. .

[0106] After redetermining the target heterogeneous computing resources, the latest resource acquisition time for the new critical task is obtained based on the end time of the corresponding stage budget, the remaining execution time, and the resource switching time. The resource release time corresponding to the new target heterogeneous computing resources is then read, and the time relationship comparison is repeated until the target heterogeneous computing resources with a resource release time no later than the latest resource acquisition time of the critical task are obtained.

[0107] After traversing all executable heterogeneous computing resources, there is still no solution that satisfies the condition. When binding heterogeneous computing resources, the resource with the earliest expected completion time is selected, and the corresponding resource action is sent to the resource controller without waiting for the original target resource. After the resource controller returns confirmation that the binding of the target heterogeneous computing resource is complete, the corresponding budget status is updated to the submitted status, and the current resource binding is updated.

[0108] For actions to be cancelled, when If the corresponding heterogeneous computing power resource action has not yet been sent to the resource controller, the corresponding resource action is cancelled directly. If the action has been sent but no actual physical resource binding has been formed, a cancellation request is sent to the resource controller. If the resource controller returns confirmation that the resource action has not been executed or has stopped executing, the corresponding resource action is cancelled. If the resource controller returns confirmation that the target heterogeneous computing power resource binding is complete before the cancellation is completed, the resource action execution flag is set. Update to 1, write the target heterogeneous computing power resources into the current resource binding, and keep it in the pending cancellation state until the corresponding resource release time is executed to release the resources. At that time, keep the current resource bound until the corresponding resource release time, and then execute the resource release.

[0109] For the migration mapping, first target the heterogeneous computing resource index after the change. The system compares the corresponding resource release time with the latest resource acquisition time of the critical task, and determines the submission time of the resource action according to the comparison result; after the target heterogeneous computing power resources have completed the actual binding and returned confirmation, the resource binding before the change is released.

[0110] For pending actions and resource actions in the migration correspondence that have received confirmation of completion of target heterogeneous computing power resource binding, a new current resource binding is formed, the corresponding budget status is updated to the submitted status, and the resource action execution flag is updated to 1; for resource actions that have entered the pending cancellation status, the pending cancellation status is maintained until the corresponding resource release time is completed and the resource release is completed.

[0111] It should also be noted that the latest resource acquisition time for critical tasks is determined based on the end time of the stage budget, the remaining execution time on the target heterogeneous computing resources, and the resource switching time. This time is then compared with the actual release time of the target resources before deciding on the timing of resource action submission. This makes "the target resource has been determined" and "whether a switch must be performed now" two different judgments. When the resource release time is no later than the latest resource acquisition time, the current resource can continue to complete its existing use, and the system waits for the resource to be released naturally before submitting the resource action. When the resource release time has exceeded the latest resource acquisition time, continuing to wait will prevent the task from being completed within the stage budget. Therefore, the current target resource is canceled and a new resource is selected from other executable resources. The time taken for switching existing resources and initial resource binding is included in the same time boundary calculation, so that the resource action judgment reflects the actual physical switching process. Compared with immediately preempting or migrating when the target resource is found to be busy, this invention changes the resource arrangement when waiting will indeed encroach on the available time window of the task. This can reduce preemption and unnecessary migration when there is still time leeway, and at the same time avoid critical tasks missing the latest resource acquisition time due to excessive waiting.

[0112] The feedback rollback module is used to adjust the time budget for the task execution phase based on the feedback, and to roll back any uncommitted resource actions.

[0113] Furthermore, the revision of the stage time budget includes: collecting the actual completion time of task nodes, comparing the actual completion time with the end time of the corresponding stage time budget to obtain the time deviation; when the actual completion time is earlier than the end time of the corresponding stage time budget, the time deviation is added to the remaining available time of the unfinished task nodes following the current critical path; when the actual completion time is later than the end time of the corresponding stage time budget, the time deviation is deducted from the remaining available time of the unfinished task nodes following the current critical path, and the corresponding stage time budget is written back based on the updated remaining available time; when the dynamic task graph version changes again, the budget status of the corresponding stage time budget is read, and the stage time budgets in the candidate state and the corresponding heterogeneous computing resource actions that have not yet formed actual resource bindings are rolled back, and the corresponding heterogeneous computing resource actions that have not formed actual resource bindings are revoked; for heterogeneous computing resource actions that have formed actual resource bindings, the current resource bindings are retained, and the latest task execution feedback is written into the new scheduling loop.

[0114] It should be noted that one specific approach to revising the phase time budget involves the following: after resource actions are submitted according to time boundaries, the scheduling result will still be affected by actual task execution deviations and subsequent changes in the task graph, especially since there is an execution process between the issuance of a resource action and the formation of an actual physical binding. If the task relationship changes again during this period, the action originally to be submitted may no longer be suitable for the new scheduling result. Therefore, it is necessary to revise the remaining phase budget based on the actual completion time, while distinguishing between resource states that have not yet formed a physical binding and those that have already formed a binding. The former should be revoked, while the latter should retain the actual binding and serve as a new scheduling starting point, thereby avoiding repeated rollbacks of resource states.

[0115] From the generation of a resource action in the task scheduling association record to the actual physical binding of the target heterogeneous computing power resource, there are intermediate processes such as resource action waiting, command sending, and resource controller execution. The dynamic task graph may change again during any of these intermediate processes. In this case, using the fact that a resource action has been generated or sent as the basis for resource state change would cause the scheduling record to change before the actual physical resource state; while restoring resource actions that have already completed physical binding to the resource binding before the change would generate additional reverse resource switching. Therefore, the task scheduling association record retains both the budget state and the resource action execution flag to distinguish between the two state boundaries of logical resource action formation and actual physical resource binding completion.

[0116] The feedback rollback module reads the task execution feedback recorded during the execution of the task program corresponding to the task node. The task execution feedback includes at least the task node identifier, the actual completion time, and the current resource binding at the time of completion. (Actual completion time...) The system monotonic clock with the same time base as the current scheduling time is read when the last scheduling segment of the task node is completed.

[0117] For completed task nodes Use phase budget end time Subtract the actual completion time of the task node Time deviation is obtained When the result is greater than 0, it indicates that the task node completed ahead of schedule, and the corresponding positive value is the time released; when the result is equal to 0, it indicates that the task node completed at the end of the stage budget; when the result is less than 0, it indicates that the task node completed late, and the corresponding absolute value is the extra time consumed.

[0118] To avoid repeatedly assigning the same time deviation to multiple task nodes, this embodiment first determines the task nodes located on the current critical path. The set of task nodes that have not yet been completed. , will set The total remaining available time for each task node is obtained by summing the current stage budget duration of each node in sequence. .

[0119] Then adjust the time deviation Add to The above provides the updated total remaining available time. Therefore, when a task node completes ahead of schedule, the total remaining available time increases by the corresponding advance amount; when a task node completes late, the total remaining available time decreases by the corresponding delay amount.

[0120] The updated time is not copied to each subsequent task node individually. Instead, it is redistributed according to the proportion of the remaining execution time of each subsequent unfinished task node to the total remaining execution time of all subsequent unfinished task nodes, as shown below:

[0121] in, Represents task node Updated stage budget duration Represents task node Current remaining execution time, Represents task node The set of subsequent unfinished task nodes in the current critical path. Represents a set The task node index in the system.

[0122] Following the order of task nodes in the current critical path, starting with task nodes... Actual completion time At the new starting point, the updated stage budget duration is added sequentially. It obtains the end time of the stage budget after the update of each subsequent task node, and writes back the stage time budget in the corresponding task scheduling association record.

[0123] When the updated total remaining available time When the value is less than or equal to 0, the end time of the stage budget of the corresponding successor task node is set to the current actual completion time, and the corresponding budget status is set to pending submission.

[0124] The feedback rollback module also handles situations where the dynamic task graph version changes again before the heterogeneous computing resource actions have completed the actual resource binding.

[0125] When a new version of the dynamic task graph is generated, the budget status is read from the existing task scheduling association records. and resource action execution flags .

[0126] For candidate states, i.e. The task scheduling association records are directly removed from the current scheduling version, along with the corresponding stage time budget and candidate heterogeneous computing resource actions.

[0127] For those in the pending submission status and The task scheduling association record first confirms whether the corresponding heterogeneous computing power resource action has been sent to the resource controller. If the resource action has not yet been sent, the corresponding pending resource action is cancelled, the pending status is cancelled, and the current resource binding of the task node remains unchanged.

[0128] If a resource action has been sent but confirmation of completion of binding with the target heterogeneous computing power resource has not yet been received, a corresponding resource action cancellation request is sent to the resource controller. Only after the resource controller returns confirmation that the corresponding resource action has not been executed or has stopped execution, will the corresponding pending resource action be cancelled and the current resource binding remain unchanged.

[0129] If the resource controller returns confirmation of successful binding of the target heterogeneous computing power resources before receiving confirmation that the resource action has not been executed or has been stopped, the budget status will be updated to the submitted status, and the resource action execution flag will be changed. Update to 1 and write the target heterogeneous computing power resources into the current resource binding.

[0130] For resource actions that have been sent to the resource controller but for which binding completion confirmation has not yet been received, the corresponding record is not directly deleted as an unexecuted action. Instead, the process waits for the resource controller to confirm the revocation request or the binding completion result, ensuring that the state changes of the task scheduling associated record are consistent with the actual execution result of the resource controller. When the binding completion confirmation returns before the revocation confirmation, the corresponding resource action has already crossed the state boundary that can be directly revoked. In this case, the resource binding before the change is not restored; instead, the actual target resource binding is used as the current resource state for subsequent dynamic task graph scheduling. Therefore, whether an actual physical resource binding has been formed serves as the boundary for whether an uncommitted resource action can be directly rolled back.

[0131] For budget status is submitted and The task scheduling association records retain the existing current resource bindings and write the corresponding current resource bindings to the latest dynamic task graph version, without restoring the resource binding state before the change.

[0132] For task scheduling association records where the budget status is pending cancellation and resource release has not yet been completed, as an optional enhanced implementation, it is possible to re-check whether the corresponding task node has re-entered the current critical path. If it re-enters the current critical path and the target heterogeneous computing power resource is still equal to the current resource binding, the pending cancellation status is canceled and it is restored to the committed status; if it does not re-enter the current critical path, the original resource release process continues.

[0133] After the task node is completed, the actual completion time will be... Execution status The actual resource binding is written back to the task node execution record, and the corresponding actual execution duration is written to the task resource execution time record.

[0134] This results in a continuous execution process including dynamic task graph version updates, affected subgraph limitations, reconstruction of the current critical path and stage time budget, association of stage time budget with heterogeneous computing power resource actions, identification of resource action differences, submission and cancellation of heterogeneous computing power resource actions, and task execution feedback correction and rollback of unsubmitted resource actions.

[0135] It should also be noted that the remaining stage budget is adjusted based on the time deviation between the actual task completion time and the stage budget end time. When the dynamic task graph changes again, the decision to roll back is based on whether resource actions have already formed actual physical bindings, ensuring that the scheduling result reflects the actual running state rather than being re-initialized each time. When a task completes ahead of schedule, the released time is added to the total remaining available time of unfinished tasks in the current critical path; when a task completes late, this total time is compressed accordingly, and the stage budget is re-divided according to the remaining execution time of each task, avoiding the same lead time being repeatedly added to multiple task nodes. For resource actions, pending actions that have not yet been sent can be directly cancelled; actions that have been sent but whose physical bindings have not yet been completed are stopped after confirmation by the resource controller; if the binding has been completed, the formed physical resource state is written back to the current resource binding, without mechanically restoring to the old resource. This addresses situations where the dynamic graph changes faster than the actual switching speed of resources such as GPUs and FPGAs, allowing logical scheduling to be withdrawn before physical actions are implemented, while the formed physical state can become a new scheduling starting point, thereby reducing resource oscillations of "switching immediately after switching back" and maintaining consistency between task execution feedback, budget state, and actual resource bindings.

Claims

1. A dynamic heterogeneous computing resource scheduling and allocation system for command and control software, characterized in that, include, Dynamic graph module, budget reconstruction module, state mapping module, difference recognition module, action control module, feedback rollback module; The dynamic graph module is used to construct a dynamic task graph version based on task nodes and dependency edges and generate affected subgraphs. The budget reconstruction module is used to reconstruct the current critical path and stage time budget based on the affected subgraph; The state mapping module is used to establish the mapping relationship between stage time budget and heterogeneous computing resource actions; The difference identification module is used to generate a set of resource action differences based on the critical path, stage time budget, and resource binding relationship. The action control module is used to control the submission and cancellation of resource actions based on the stage time budget and the resource release time. The feedback rollback module is used to correct the time budget of the task execution feedback phase and to roll back any unsubmitted resource actions.

2. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 1, characterized in that: The process of constructing a dynamic task graph version and generating an affected subgraph includes: establishing a dynamic task graph version according to the dependency relationship between task nodes; writing the task node identifier, execution status and resource binding relationship into the corresponding task node; and establishing a dependency edge with two task nodes that have a dependency relationship. When the set of task nodes and the set of dependent edges change, save the dynamic task graph version before the change, and generate a new dynamic task graph version based on the changed set of task nodes and the set of dependent edges. Compare the task node identifiers and dependency edge endpoint combinations in the two versions of the dynamic task graph to determine the locations where changes such as additions, deletions, branch undoings, and path mergings have occurred. Extend upstream and downstream from the changed position along the dependency edge to the boundary node where the connection relationship has not changed. Form the affected subgraph by the task nodes and dependency edges within the extended range, and write the affected subgraph into the new dynamic task graph version.

3. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 2, characterized in that: The reconstruction of the current critical path and stage time budget includes traversing from the entry task node of the affected subgraph along the dependency edges to the exit task node to form candidate dependency paths containing the affected subgraph. Read the remaining execution time of each task node in the candidate dependency path, and add up the remaining execution time of each task node according to their order in the candidate dependency path to obtain the remaining path time of each candidate dependency path; Subtract the remaining path time from the time between the end-to-end completion time of the task chain and the current time to obtain the path time margin of each candidate dependency path. The candidate dependency path with the smallest path time margin is determined as the current critical path. Based on the remaining execution time of the unfinished task nodes in the current critical path and the remaining available time of the current critical path, the remaining available time is divided according to the proportion of the remaining execution time, and the stage time budget corresponding to each unfinished task node is generated.

4. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 3, characterized in that: The mapping relationship between the establishment phase time budget and heterogeneous computing resource actions includes configuring candidate status, pending submission status, submitted status and pending cancellation status for each phase time budget, and establishing a budget association between the phase time budget and the corresponding task node. Read the heterogeneous computing resources that can be executed by the corresponding task node and the task execution time corresponding to each heterogeneous computing resource. Combine the available time of each heterogeneous computing resource to obtain the expected completion time of the task node on each heterogeneous computing resource. Retain heterogeneous computing resources whose expected completion time is no later than the end time of the corresponding stage's time budget, and determine the target heterogeneous computing resources from the retention results.

5. The dynamic heterogeneous computing power resource scheduling and allocation system for command and control software as described in claim 4, characterized in that: The mapping relationship between the establishment phase time budget and heterogeneous computing resource actions also includes comparing the current resource binding of the task node with the target heterogeneous computing resource to form the corresponding heterogeneous computing resource action; Using the task node identifier as the association key, the time budget, budget status, and heterogeneous computing resource actions of the corresponding stage are written into the same task scheduling association record.

6. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 5, characterized in that: The process of generating the resource action difference set includes reading the critical path, stage time budget and resource binding relationship before and after the task graph change, respectively, to form the resource action set before the change and the resource action set after the change. The resource action set before the change and the resource action set after the change are paired according to the task node identifier. When the target heterogeneous computing power resources are the same after pairing, the corresponding resource action is written into the hold action set. If the task node corresponding to the resource action before the change does not exist in the resource action set after the change, the corresponding resource action will be written into the action set to be undone. If the task node corresponding to the changed resource action does not exist in the resource action set before the change, the corresponding resource action will be written into the action set to be submitted.

7. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 6, characterized in that: The process of generating the resource action difference set also includes, when the paired task nodes are the same and the target heterogeneous computing resources are different, establishing a migration correspondence between the resource actions before the change and the resource actions after the change, and forming a resource action difference set by the set of actions to be maintained, the set of actions to be undone, the set of actions to be submitted, and the migration correspondence.

8. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 7, characterized in that: The submission and cancellation of the control resource action includes reading the end time of the time budget of the stage corresponding to the action to be submitted, the remaining execution time of the corresponding task node on the target heterogeneous computing power resource, and the resource switching time. The remaining execution time and resource switching time are subtracted from the end time of the stage time budget in sequence to obtain the latest resource acquisition time of the critical task. Read the remaining time occupied by the currently executing task of the target heterogeneous computing power resource, and obtain the resource release time based on the current time and the remaining time occupied; Compare the latest resource acquisition time and resource release time of the critical task. If the resource release time is not later than the latest resource acquisition time of the critical task, keep the current resource bound to the resource release time, and submit the corresponding pending action after the resource is released. When the resource release time is later than the latest resource acquisition time of the critical task, cancel the current target heterogeneous computing power resource as the target of the pending action, and re-determine the heterogeneous computing power resources that meet the stage time budget. For actions to be revoked, if the corresponding heterogeneous computing resource action has not yet formed an actual resource binding, the corresponding heterogeneous computing resource action will be revoked. If the corresponding heterogeneous computing resource action has formed an actual resource binding, the current resource binding will be maintained until the resource release time, after which the resource release will be executed.

9. The dynamic heterogeneous computing power resource scheduling and allocation system for command and control software as described in claim 8, characterized in that: The time budget for the correction phase includes collecting the actual completion time of the task nodes, comparing the actual completion time with the end time of the corresponding phase time budget, and obtaining the time deviation. When the actual completion time is earlier than the end time of the corresponding stage's time budget, the time deviation will be added to the remaining available time of the unfinished task nodes following the current critical path. When the actual completion time is later than the end time of the corresponding stage time budget, the time deviation is deducted from the remaining available time of the unfinished task nodes following the current critical path, and the corresponding stage time budget is rewritten based on the updated remaining available time.

10. The dynamic heterogeneous computing resource scheduling and allocation system for command and control software as described in claim 9, characterized in that: The rollback of unsubmitted resource actions includes, when the dynamic task graph version changes again, reading the budget status of the corresponding stage time budget, rolling back the stage time budget in the candidate state and the stage time budget in the pending state that has not yet formed actual resource binding for the corresponding heterogeneous computing power resource actions, and canceling the corresponding heterogeneous computing power resource actions that have not formed actual resource binding. For heterogeneous computing resources that have already formed actual resource bindings, the current resource bindings are retained, and the latest task execution feedback is written into the new scheduling loop.

Images