Task scheduling system and electronic equipment

Abstract

The embodiment of the utility model discloses a task scheduling system and electronic equipment, the task scheduling system of the embodiment of the utility model comprises at least one task scheduling module, the task scheduling module comprises a first cache unit used for caching an initial scheduling command, and a second cache unit used for caching an initial scheduling command. The first engine is used for storing information of at least one task node corresponding to the initial scheduling command; and the second engine is used for caching executable task node information received from the first engine and sending the executable task node to the execution engine for processing. Wherein the initial scheduling command is used for triggering at least one task, and the information of the task nodes comprises the dependency relationship of the task nodes. Therefore, the task scheduling system provided by the embodiment of the utility model can improve the degree of parallelism of the single first cache unit, and the task commands can be scheduled and executed when being executed, so that the mutual blocking of different task commands is avoided, and the task scheduling efficiency is further improved.

Description

Technical Field

[0001] The utility model relates to the technical field of computers, and more specifically, to a task scheduling system and electronic equipment. Background Art

[0002] Computer processors, such as GPUs (Graphics Processing Units) and GPGPUs (General Purpose Graphics Processing Units), contain numerous computing cores. A large task is broken down into multiple subtasks and assigned to different computing cores. Multiple smaller tasks can also be submitted to the processor simultaneously and processed in parallel by different cores. Therefore, efficient task scheduling is crucial to fully utilizing the computing power of computer processors. Utility Model Content

[0003] In view of this, an embodiment of the present invention provides a task scheduling system and an electronic device, so as to improve the parallelism of a single first cache unit based on the dependency between the initial scheduling command and the task node through the first engine and the second engine, and to schedule the execution of the task command when it can be executed, thereby avoiding mutual blocking of different task commands, thereby improving the task scheduling efficiency.

[0004] In a first aspect, an embodiment of the present invention provides a task scheduling system, wherein the task scheduling system includes at least one task scheduling module, and the task scheduling module includes:

[0005] A first cache unit, configured to cache an initial scheduling command, where the initial scheduling command is used to trigger at least one task;

[0006] a first engine, communicatively connected to the first buffer area, configured to store information of at least one task node corresponding to the initial scheduling command, wherein the information of the task node includes a dependency relationship of the task node;

[0007] The second engine is connected to the first engine for buffering the executable task node information received from the first engine and sending the executable task node to the execution engine for processing.

[0008] Optionally, the first cache unit includes:

[0009] A memory access module is connected to a predetermined storage unit for sending a task scheduling request to the predetermined storage unit according to the configuration information, wherein the predetermined storage unit is used to store task node information corresponding to the task to be executed;

[0010] a command caching module, communicatively connected to the predetermined storage unit, and configured to cache at least one initial scheduling command fed back by the predetermined storage unit;

[0011] A command decoder is communicatively connected to the command cache module and the first engine, and is configured to read the initial scheduling command from the command cache module and send the command to the first engine.

[0012] Optionally, the first cache unit is a linear ring cache unit.

[0013] Optionally, the first engine includes a node cache module, and the node cache module is used to cache the initial scheduling command or task node information.

[0014] Optionally, the node cache module includes multiple cache partitions, and the cache partitions are used to cache at least one task node information in the corresponding task node tree, and the task node tree includes multiple task nodes with dependency relationships.

[0015] Optionally, the first engine further includes:

[0016] an information receiving module, communicatively connected to the first cache unit, the second engine, and the predetermined storage unit, configured to receive the initial scheduling command sent by the first cache unit, the executed task node information fed back by the second engine, and read the unexecuted task node information from the predetermined storage unit;

[0017] A task parsing module is communicatively connected to the node cache module and the second engine, and is used to obtain unexecuted task node information from the node cache module and send the task node information to the second engine when the task node information includes a currently executable task execution command.

[0018] Optionally, the task parsing module is further configured to send a task read request to the predetermined storage unit, so that the predetermined storage unit feeds back the corresponding unexecuted task node information to the information receiving module.

[0019] Optionally, the task node information in the cache partition is updated according to the executed task node information fed back by the second engine and the task node tree.

[0020] Optionally, the node cache module includes:

[0021] The first storage area is used to store control information of the task node;

[0022] The second storage area is used to store task node information.

[0023] Optionally, the second engine includes:

[0024] A first task cache module is connected to the first engine and the execution engine for receiving a task execution command corresponding to a task node sent by the first engine;

[0025] The second task cache module is connected to the first engine and the execution engine for caching and updating the received task node information.

[0026] Optionally, a fence synchronization mechanism is adopted between different task scheduling modules.

[0027] In a second aspect, an embodiment of the present invention provides an electronic device comprising a memory and a processor, wherein the memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor using the task scheduling system as described above.

[0028] The task scheduling system of the embodiment of the present utility model includes at least one task scheduling module, and the task scheduling module includes a first cache unit for caching an initial scheduling command, a first engine for storing information of at least one task node corresponding to the initial scheduling command, and a second engine for caching information of executable task nodes received from the first engine and sending the executable task nodes to the execution engine for processing. The initial scheduling command is used to trigger at least one task, and the information of the task nodes includes the dependency relationship of the task nodes. Thus, the task scheduling system of the embodiment of the present utility model can improve the parallelism of a single first cache unit based on the dependency relationship between the initial scheduling command and the task node through the first engine and the second engine, and avoid mutual blocking of different task commands when the task command can be scheduled for execution when it can be executed, thereby improving the task scheduling efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0030] Figure 1 This is a comparative task scheduling diagram;

[0031] Figure 2 This is a comparative diagram of the task scheduling hardware structure;

[0032] Figure 3 This is a schematic diagram of forming a task node tree according to an embodiment of the present invention;

[0033] Figure 4 This is a schematic diagram of a task scheduling system according to an embodiment of the present utility model;

[0034] Figure 5This is a schematic diagram of the software and hardware interface of an embodiment of the utility model;

[0035] Figure 6 It is a structural diagram of the first cache unit of an embodiment of the present utility model;

[0036] Figure 7 This is a structural diagram of a first engine according to an embodiment of the present utility model;

[0037] Figure 8 This is a schematic diagram of the working process of a first engine according to an embodiment of the present utility model;

[0038] Figure 9 This is a schematic diagram of another working process of the first engine according to an embodiment of the present utility model;

[0039] Figure 10 This is a structural diagram of another first engine according to an embodiment of the present utility model;

[0040] Figure 11 This is a structural diagram of a second engine according to an embodiment of the present utility model;

[0041] Figure 12 is a flow chart of a task scheduling method according to an embodiment of the present utility model;

[0042] Figure 13 Schematic diagram of a task scheduling device according to an embodiment of the present invention;

[0043] Figure 14 Schematic diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0044] The present application is described below based on the following embodiments, but the present application is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without the description of these details. To avoid obscuring the essence of the present application, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0045] Furthermore, persons of ordinary skill in the art will appreciate that the figures provided herein are for illustration purposes only and are not necessarily drawn to scale.

[0046] Unless the context clearly requires otherwise, words like “include”, “comprising” and the like throughout this application should be interpreted as including rather than exclusive or exhaustive; that is, as meaning “including but not limited to”.

[0047] In the description of this application, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and should not be understood to indicate or imply relative importance. In addition, in the description of this application, unless otherwise specified, "plurality" means two or more.

[0048] In related comparative examples, a linear ring buffer is typically used to implement computer processing scheduling. Taking a GPGPU processor as an example, the user submits tasks to the hardware device in the form of a data stream. A stream is a linear sequence of commands, i.e., the data stream formed by the command sequences corresponding to the tasks. It should be understood that in actual applications, the user can assign a task to one or more streams, or multiple tasks to the same stream.

[0049] Figure 1 This is a comparative task scheduling diagram. Figure 1 As shown, the corresponding driver is used to read the stream and write the read command into the ring buffer 1. The ring buffer 1 has a baseline and maintains a write pointer wptr and a read pointer rptr. The hardware device starts working by reading the command based on the read pointer rptr, and updates the read pointer rptr to indicate that the corresponding command has been executed and the corresponding space can be released. In addition, when the driver writes the command into the ring buffer 1, it updates the position pointed to by the write pointer wptr. Figure 1 As shown, the position between the write pointer wptr and the read pointer rptr of the ring buffer area 1 stores the commands to be executed, the area between the write pointer wptr and the cache start point is the unused cache area (Free Space), and the area between the cache start point and the read pointer rptr is the area released by the executed commands.

[0050] Because commands in a stream may have dependencies, the comparison example also uses a fence-semaphore mechanism to handle these dependencies. Specifically, this mechanism employs the WAIT_FENCE and FENCE commands. The WAIT_FENCE command instructs the cache that executes this command to wait until a value in a specified memory location meets certain conditions, while the FENCE command writes a specific value to the specified memory location.

[0051] Figure 2This is a comparative diagram of the task scheduling hardware structure. Since each ring buffer requires a certain amount of physical resources, only a limited number of K HW ring buffers can be provided physically. Different ring buffers can be executed in parallel. The driver divides each task and writes the task into the selected ring buffer in a linear manner. The hardware device then retrieves and executes the corresponding task according to the address given by the driver. Figure 2 As shown, taking the two ring buffers ring0 and ring1 as an example, in ring0, Task0 / Task1 / Task2 are written linearly, where Task1 depends on Task0. In ring1, Task3 and Task4 are written linearly, where Task4 depends on Task3. Therefore, the driver will write an additional fence-semaphore (i.e., fence0 and wait_fence0 commands) between Task0 and Task1 to ensure the execution order of Task0 and Task1, and an additional fence-semaphore (i.e., fence3 and wait_fence3 commands) between Task3 and Task4 to ensure the execution order of Task3 and Task4. Furthermore, the processing engine obtains the executable tasks in ring0 or ring1 for corresponding processing. Among them, Task2 does not depend on Task0, but still needs to wait for the completion of Task0.

[0052] At the same time, Ring Buffer is a hardware resource, and due to cost constraints, the number is often only a few to dozens. Stream is a software resource, created by the user end. In a multi-process multi-stream scenario, the number of streams may be as many as hundreds or thousands. Therefore, the driver may map multiple streams to the same Ring Buffer. Since Ring Buffer is a linear structure, WAIT_FENCE blocks the entire Ring Buffer, which may introduce false dependencies between independent streams. It can be seen that in this comparative example, due to the limitation of physical hardware resources, the parallelism of task processing is low, and the fence-semaphore mechanism brings additional memory access overhead, and tasks within the same Ring Buffer may be forced to form mutual blocking, thereby affecting task scheduling performance. Therefore, an embodiment of the present utility model provides a task scheduling system and an electronic device, which can improve the parallelism of a single first cache unit based on the dependency between the initial scheduling command and the task node through a first engine and a second engine, and can schedule execution when the task command can be executed to avoid mutual blocking of different task commands, thereby improving task scheduling efficiency.

[0053] In an embodiment of the present invention, by processing the task data flow and the dependencies between tasks from a holistic perspective, tasks with dependencies are combined into a tree or graph, and a corresponding task scheduling system is designed to traverse the tree or graph to improve the parallelism of task scheduling and thereby improve the efficiency of task scheduling.

[0054] Figure 3 Schematic diagram of the task node tree formation of an embodiment of the present invention. After obtaining different tasks submitted by the user end through multiple SW streams (Software streams) created, this embodiment connects the tasks according to the dependency relationship to form a graph structure (or tree structure). It should be understood that the tasks submitted by the user end through the SW stream can be multiple subtasks divided from a large task (such as multiple subtasks corresponding to an AI model), or a combination of multiple small tasks, and this embodiment does not limit this.

[0055] like Figure 3 As shown, taking the task streams stream0, stream1 and stream2 as an example, the corresponding graph structure 3 (or tree structure) is constructed through the dependency relationship between the tasks in the task streams stream0, stream1 and stream2. The directed lines in the graph structure 3 represent the task dependency relationship. Among them, the task stream stream0 includes tasks 01-03, the task stream stream1 includes tasks 11-13, and the task stream stream2 includes tasks 21-23. The numbers in the node identifiers of each task represent the number of nodes that the corresponding task depends on. For example, the execution of task 02 in the task stream 0 only needs to rely on the execution result of task 01 in the task stream 0. The number in the node identifier corresponding to task 02 is 1. The execution of task 12 in the task stream 1 needs to rely on the execution results of tasks 01, task 11 and task 21. The number in the node identifier corresponding to task 02 is 3.

[0056] Furthermore, in order to process the dependency flow, the embodiment of the present invention defines each node in the graph structure 3 as a scheduling command (sched cmd), and the information of each task node (sched cmd) includes dependency information and task information. Among them, the dependency information includes the dependency value depcnt (dependency counter) and the node pointer. The task information includes the task (task) carried by the task node. The dependency value depcnt is used to represent the count value of the unexecuted predecessor task node on which the corresponding task node depends. When the dependency value depcnt=0, it represents that the predecessor task node on which the corresponding task node depends has been completed. The task node can be changed to an executable state, and the task command (task) it carries can be executed at any time. For example, if the task 01 in the predecessor node task stream 0 on which it depends has not been executed, then the dependency value depcnt corresponding to the task 02 in the task stream 0 is 1. If the task 01 in the predecessor node task stream 0 on which it depends has been executed, then the dependency value depcnt corresponding to the task 02 in the task stream 0 is 0.

[0057] In an optional implementation, a task node has a corresponding predetermined number of node pointers. The node pointer is used to point to the post-task node that depends on the task node. When the task node is executed, the dependency value depcnt corresponding to the post-task node pointed to by the task node is reduced by 1. Further optionally, when the other tasks that depend on a certain task exceed a predetermined number, the task can be mapped to multiple task node cascades (i.e., multiple sched cmd cascades). It should be understood that the present embodiment does not limit the number of node pointers corresponding to the task node, and it can be set based on actual hardware performance and efficiency requirements. The present embodiment is described in detail below mainly by taking the task node having two corresponding node pointers as an example. Taking task 02 in task stream 0 as an example, one of the node pointers corresponding to task 02 is used to point to task 03 in task stream 0. Taking task 12 in task stream 1 as an example, it requires 3 node pointers to point to task 03 in task stream 0, task 13 in task stream 1, and task 23 in task stream 2 respectively. Therefore, task 12 can be mapped to a cascade of two task nodes, so that the two node pointers of one task node point to task 03 in task stream 0 and task 13 in task stream 1 respectively, and one node pointer of the other task node points to task 23 in task stream 2.

[0058] In an optional implementation, during the construction of the graph structure, a node that does not carry task execution commands and only serves as a processing dependency flow (which may be called an Aux-Sched cmd) can be inserted into the graph structure to further facilitate the expression of dependency flows between tasks and further facilitate subsequent task scheduling.

[0059] Furthermore, the embodiment of the present invention stores the graph structure (or tree structure) in a predetermined storage unit, and traverses the subtrees in the graph structure in parallel using the task scheduling system of the embodiment of the present invention. It should be understood that the subtrees in this embodiment are DAGs (directed acyclic graphs) partitioned from the larger graph structure. Optionally, the subtrees in this embodiment are partitioned during the dynamic operation of the task scheduling system.

[0060] Figure 4 This is a schematic diagram of a task scheduling system according to an embodiment of the present utility model. Figure 4 As shown, the task scheduling system 40 of the embodiment of the present invention includes at least one task scheduling module 41. The task scheduling module 41 includes a first cache unit 411, a first engine 412, and a second engine 413. The first cache unit 411 is in communication with the first engine 412, and the first engine 412 is in communication with the second engine 413.

[0061] In an optional implementation, the first cache unit 411 is a linear cache unit. Further optionally, the first cache unit is a linear ring buffer. The first cache unit 411 is used to cache an initial scheduling command. The initial scheduling command is used to trigger at least one task.

[0062] Furthermore, this embodiment implements the interaction between software and hardware through a software and hardware interface. Optionally, this embodiment can write each initial scheduling command (rbsched) into the first cache unit 411 through a device driver. It should be understood that this embodiment is not limited to the device driver, and this embodiment can also be implemented using other software and hardware interfaces, such as a register interface, a bus interface, etc. Optionally, the initial scheduling command in this embodiment can be determined based on the dependency relationship between tasks. Further optionally, there may be no dependency relationship or there may be a dependency relationship between the tasks triggered by different initial scheduling commands. Thus, this embodiment can write at least one initial scheduling command into the first cache unit 411 through a software and hardware interface, so that the first engine 412 traverses the graph structure in the predetermined storage unit 50 by reading the initial scheduling command in the first cache unit 411.

[0063] Figure 5 This is a schematic diagram of the software and hardware interface of the embodiment of the utility model. Figure 5 As shown, taking task streams stream0, stream1, and stream2 as an example, this embodiment can write the initial scheduling commands rbsched1 and rbsched2 corresponding to tasks task1-5 in task streams stream0, stream1, and stream2 into the ringbuffer (i.e., the first cache unit 411) through a device driver based on an API interface.

[0064] Figure 6 This is a schematic diagram of the structure of the first cache unit of the embodiment of the present utility model. Figure 6 As shown, the first cache unit 411 includes a memory access module 61, a command cache module 62, and a command decoder 63. The memory access module 61 is in communication with the predetermined storage unit 50, and the command cache module 62 is in communication with the predetermined storage unit 50 and the command decoder 63. The command decoder 63 is in communication with the command cache module 62 and the first engine 412.

[0065] The memory access module 61 is used to send a task scheduling request req1 to the predetermined storage unit 50 according to the configuration information. The configuration information may include the baseline (Base), write pointer, read pointer of the first cache unit, and the access address of the predetermined storage unit 50.

[0066] In an optional implementation, the memory access module 61 can be implemented using DMA (Direct Memory Access). DMA is a technology that allows hardware devices to directly read and write system memory. Thus, the memory access module 61 can send a task scheduling request req1 to the predetermined storage unit 50 based on the configuration information to directly read the initial scheduling command rbsched from the predetermined storage unit 50. It should be understood that the memory access module 61 of this embodiment is not limited to DMA; other memory access modes that can be used to access the predetermined storage unit 50 can also be applied to the memory access module 61, and these will not be illustrated one by one here.

[0067] After receiving the task scheduling request req1, the predetermined storage unit 50 obtains the corresponding at least one initial scheduling command rbsched and sends feedback information rsq1 to the command cache module 62. The feedback information rsq1 includes one or more initial scheduling commands rbsched.

[0068] The command cache module 62 is used to cache at least one initial scheduling command fed back by a predetermined storage unit. In an optional implementation, the command cache module 62 can be implemented using a cmd fifo (command fifo). A cmd fifo is a first-in-first-out data structure used to store commands or instructions to be executed.

[0069] The command decoder 63 is configured to read the initial scheduling command rbsched from the command cache module 62 and send it to the first engine 412. The command decoder 63 is configured to read the original initial scheduling command rbsched from the command cache module 62 and convert it into a format that can be directly understood by the corresponding computer processor to ensure that the initial scheduling command rbsched can be correctly executed on the execution engine of the computer processor.

[0070] The first engine 412 is used to store information about at least one task node corresponding to the initial scheduling command. The information about the task node (sched cmd) includes the dependencies of the task nodes. In this embodiment, the first engine 412 can be a walk engine, which is a hardware component used to generate and manage complex memory access patterns.

[0071] Figure 7 This is a schematic diagram of the structure of a first engine in an embodiment of the present utility model. In an optional implementation, as Figure 7 As shown, the first engine 412 includes a node cache module 72. The node cache module 72 is used to cache the initial scheduling command rbsched or task node information (sched cmd). Optionally, the node cache module 72 includes multiple cache partitions (slots). The cache partition (slot) is used to cache at least one task node information in the corresponding task node tree (i.e., the above-mentioned subtree). Among them, the task node tree includes multiple task nodes with a dependency relationship. It should be understood that in this embodiment, the root node of the task node tree corresponding to each cache partition is updated as the dynamic execution process. The task node information in the cache partition is updated according to the executed task node information and task node tree feedback from the second engine.

[0072] Furthermore, the first engine 412 further includes an information receiving module 71 and a task parsing module 73. The information receiving module 71 is in communication with the first cache unit 411, the second engine 413, and the predetermined storage unit 50. The task parsing module 73 is in communication with the node cache module 72 and the second engine 413.

[0073] The information receiving module 71 is configured to receive the initial scheduling command rbsched sent by the first cache unit 411, the executed task node information fed back by the second engine 413, and read the unexecuted task node information from the predetermined storage unit 50. The task parsing module 73 is configured to obtain the unexecuted task node information from the node cache module 72 and, if the task node information includes a currently executable task execution command, send the task node information to the second engine 413.

[0074] Furthermore, the task parsing module 73 is further configured to send a task read request to the reservation storage unit 50, so that the reservation storage unit 50 feeds back the corresponding unexecuted task node information to the information receiving module 71. Specifically, the task parsing module 73 is further configured to send a task read request req2 to the reservation storage unit 50, so that the reservation storage unit 50 generates response information rsq2 based on the task read request req2, and feeds back the response information rsq2 to the information receiving module 71. The response information rsq2 includes the corresponding unexecuted task node information.

[0075] Furthermore, the task node information cached by the cache partition (slot) may include root node information, leaf node information, and / or trunk node information. Among them, the corresponding initial scheduling command rbsched or the executed task node information returned by the second engine 413 (i.e., the sched cmd returned by the second engine 413 (the task it carries has been executed)) can all be used as the root node (root node) of the task node tree. The task node sched cmd (currently not executable) whose dependency value (depcnt) is not 0, the task node sched cmd (currently executable) whose dependency value (depcnt) is 0 and carries a task, and the node that no longer needs to trigger subsequent task nodes sched cmd can all be used as the leaf node (leafnode) of the task node tree. The trunk node (trunk node) is also a node that is not a root node or a leaf node.

[0076] In an optional implementation, the update process of the cache partition in the node cache module 72 can be: when the initial scheduling command or the task node traversed from the task node tree applies for the corresponding new cache partition, the initial scheduling command or the traversed task node is cached as the root node to the new cache partition. It should be understood that if the task node traversed from the task node tree needs to apply for a new cache partition, a new task node tree representing the task node as the root node is created. Furthermore, the update process of the cache partition in the node cache module 72 can also be: in response to the task node information in the cache partition representing that the task has been executed, the corresponding task node tree is traversed according to the dependency relationship of the executed task node, the corresponding task node information is obtained from the task node tree and the cache partition is updated.

[0077] The task analysis module 73 analyzes the task node information cached in the cache partition, obtains executable task nodes, and sends the executable task nodes to the second engine 413. Furthermore, the task analysis module 73 may determine the root node applied to the cache partition as an executable task node. The task analysis module 73 may also determine leaf nodes carrying a task command (task) and having a dependency value of 0 as executable task nodes. The dependency value represents the number of unexecuted task nodes that the corresponding task node depends on. The task analysis module 73 sends the executable leaf nodes to the second engine 413 for dispatch, so that the corresponding task command can be executed by the execution engine. The task analysis module 73 may also determine trunk nodes with a branch count less than or equal to the idle parameter in the cache partition as executable nodes. The task analysis module 73 executes the executable trunk nodes to generate a task read request for accessing the predetermined storage unit 50. The predetermined storage unit 50 reads the corresponding task node based on the received task read request and feeds it back to the information receiving module 71. The cache partition includes multiple cache locations, each of which can cache information about a single task node. The idle parameter is determined according to the idle position (entry) in the cache partition. Optionally, the idle parameter = idle position + 1. It should be understood that this embodiment does not limit the specific determination method of the idle parameter, and it can be applied to specific scenarios. Furthermore, the task parsing module 73 is also used to discard unexecutable nodes, such as leaf nodes whose dependency values ​​are not 0 (depcnt!=0) or nodes without subsequent nodes. The task parsing module 73 is also used to execute the trunk node to obtain the node pointer of the trunk node, generate a task read request req2 corresponding to the task node pointed to by the trunk node, and send the task read request req2 to the predetermined storage unit 50, so that the predetermined storage unit 50 generates a response information rsq2 according to the task read request req2, and feeds back the response information rsq2 to the information receiving module 71.

[0078] Figure 8 : is a schematic diagram of the working process of the first engine of the embodiment of the present utility model. The working process of the first engine is described below with an example. Figure 8As shown, the first engine 412 includes i (i is greater than or equal to 1) cache partitions slot0-sloti, and each cache partition includes 2 cache location entries. The first engine 412 reads the initial scheduling command rbsched0 from the first cache unit 411, and applies for a cache partition slot0 from the first engine 412, and caches the initial scheduling command rbsched0 to a cache location in the cache partition slot0. The first engine 412 traverses the corresponding task node tree tree1 in the predetermined storage unit 50 according to the initial scheduling command rbsched0. In this embodiment, the initial scheduling command rbsched0 is used as the root node in the task node tree tree1, that is, Figure 8 The task node schedcmd1 in the task node tree tree1 in the task node tree is shown in Figure 1. The current trunk nodes of the task node tree tree1 include schedcmd2, schedcmd5, and schedcmd3. The current leaf nodes of the task node tree1 include schedcmd4, schedcmd6, and schedcmd7.

[0079] Furthermore, the task parsing module 73 in the first engine 412 can determine the root node schedcmd1 applied to the cache partition as an executable task node, and send the root node schedcmd1 to the second engine 413 for dispatch. The second engine 413 dispatches the root node schedcmd1 to the execution engine 60 for execution, and updates the information of the root node schedcmd1 after receiving the task execution completion message, and returns the updated information of the executed root node schedcmd1 to the first engine 412. The first engine 412 further traverses the task node tree tree1 according to the node pointer of the executed root node schedcmd1, reads the trunk nodes schedcmd2 and schedcmd3, and caches them in two cache locations in the cache partition slot0.

[0080] For the trunk node schedcmd2, the corresponding branch number is 1, and the free position in the cache partition slot0 is 0, that is, the branch number = the free position number + 1. As defined above, the trunk node does not carry the task command task. Since the trunk node schedcmd2 meets the execution condition (that is, the branch number = the free position number + 1), the first engine 412 executes the trunk node schedcmd2 to generate a task read request according to the node pointer of the trunk node schedcmd2, thereby reading the trunk node schedcmd5 pointed to by the trunk node schedcmd2 from the predetermined storage unit 50 based on the task read request, and caches the trunk node schedcmd5 to the first cache position in the cache partition slot0.

[0081] For the trunk node schedcmd3, its corresponding branch number is 1, and the free position in the cache partition slot0 is 0, that is, the number of branches = the number of free positions + 1. Therefore, the first engine 412 executes the trunk node schedcmd3 to generate a task read request according to the node pointer of the trunk node schedcmd3, and thereby reads the leaf node schedcmd4 pointed to by the trunk node schedcmd3 from the predetermined storage unit 50 based on the task read request, and caches the trunk node schedcmd4 to the second cache position in the cache partition slot0.

[0082] For the backbone node schedcmd5, the corresponding number of branches is 2, and the number of free locations in the cache partition slot0 is 0, that is, the number of branches is greater than the number of free locations + 1. At this time, if the backbone node schedcmd5 is determined to be an executable node, the leaf nodes schedcmd6 and schedcmd7 pointed to by its node pointer cannot be cached in the cache partition slot0. In this regard, in an optional implementation, the backbone node schedcmd5 of this embodiment can wait for the second cache location in the cache partition slot0 to be released after the leaf node schedcmd4 is executed before executing.

[0083] like Figure 8 As shown, after the leaf node schedcmd4 is executed and the second cache location in the cache partition slot0 is released, the number of free locations in the cache partition slot0 is 1. At this time, the number of branches of the trunk node schedcmd5 = the number of free locations + 1. Therefore, the first engine 412 executes the trunk node schedcmd5 to generate a task read request according to the node pointer of the trunk node schedcmd5, thereby reading the leaf node schedcmd6 and the leaf node 7 pointed to by the trunk node schedcmd5 from the predetermined storage unit 50 based on the task read request, and caches the leaf nodes schedcmd6 and the leaf node 7 to the cache location in the cache partition slot0.

[0084] In another optional implementation, when the number of branches of a trunk node is greater than the corresponding idle parameter, an empty task node (nop node) corresponding to the trunk node can be created, and after the empty task node is executed, a new cache partition is applied as the root node (root) to continue processing the original trunk node based on the new cache partition. Among them, the empty task node points to the corresponding trunk node. It should be understood that at this time, a new task node tree is formed with the empty task node as the root node.

[0085] Further optionally, if the cache partition includes multiple trunk nodes, and the number of branches of the trunk node is greater than the idle parameter, create at least one empty task node corresponding to the trunk node, and determine the empty task node as an executable task node. If the cache partition includes multiple trunk nodes, and the number of branches of the trunk node is greater than the idle parameter, it is impossible to continue the task execution by waiting for other branches to be executed. This embodiment creates an empty task node corresponding to at least one trunk node, determines the empty task node as an executable task node, and uses the executed empty task node returned by the second engine as the root node to apply for a new cache partition, so as to continue processing the original trunk node based on the new cache partition.

[0086] In an optional implementation, the above-mentioned empty task node can be created when constructing the overall graph structure, or can be created when traversing to the corresponding trunk node. This embodiment does not limit the creation timing of the empty task node.

[0087] Figure 9 This is another schematic diagram of the working process of the first engine of the embodiment of the present utility model. Figure 9 As shown, when the first engine 412 traverses the task node tree tree2, if the trunk nodes schedcmd2' and schedcmd3' are read and cached in the cache partition slot0, the number of branches for the trunk nodes schedcmd2' and schedcmd3' is greater than the number of free positions + 1, and it is impossible to handle it by waiting for other nodes to complete execution and release the cache position. Therefore, this embodiment can create an empty task node corresponding to one or more trunk nodes, such as Figure 9 The task node tree tree2' shown creates a preceding empty task node nop corresponding to the trunk node schedcmd3', so that one of the node pointers of the root node schedcmd1' points to the empty task node nop, and one of the node pointers of the empty task node nop points to schedcmd3'.

[0088] In this case, after the root node schedcmd1' is executed, the first engine 412 traverses the task node tree tree2', reads and caches the trunk node schedcmd2' and the empty task node nop in the cache partition slot0. For the trunk node schedcmd2', the number of branches is greater than the number of free positions + 1, and it is necessary to wait for the empty task node nop to be executed and release the cache position. For the empty task node nop, the number of branches is 1, so the number of branches = the number of free positions + 1. The task parsing module 73 can send the empty task node nop as an executable node to the second engine 413. The second engine 413 dispatches the empty task node nop to the execution engine 60 for execution, and updates the information of the empty task node nop after receiving the message that the task execution is completed, and returns the updated information of the executed empty task node nop to the first engine 412. At this point, after the empty task node nop is executed, the empty task node nop is controlled as the root node to apply for a new cache partition slot1 in the first engine 412, and the executed empty task node nop is cached in cache partition slot1, and the corresponding cache location in cache partition slot0 is released. At this point, for the trunk node schedcmd2', the number of branches = the number of free locations + 1, and the trunk node schedcmd2' can be executed as an executable node to generate a corresponding task read request. Based on this task read request, the leaf nodes schedcmd4' and schedcmd5' pointed to by the trunk node schedcmd2' are read from the predetermined storage unit 50, and the leaf nodes schedcmd4' and schedcmd5' are cached in cache partition slot0. Furthermore, after receiving the information from the second engine that the empty task node nop has been executed, the first engine 412 obtains the task node schedcmd3' pointed to by the empty task node nop from the task node tree tree2' based on the node pointer of the empty task node nop, and caches the task node schedcmd3' to a cache location in cache partition slot1.

[0089] Therefore, the first engine of the embodiment of the present invention can traverse the subgraph (ie, the task node tree) in the graph structure formed by multiple task streams in parallel, thereby improving the task scheduling efficiency.

[0090] Figure 10 : is a schematic diagram of the structure of another first engine of the embodiment of the utility model. In an optional implementation, as Figure 10As shown, the first engine 412 includes an information receiving module 101, a node caching module 102, and a task parsing module 103. The information receiving module 101 is in communication with the first cache unit 411, the second engine 413, and the predetermined storage unit 50. The information receiving module 101 is configured to receive the initial scheduling command rbsched sent by the first cache unit 411, the executed task node information fed back by the second engine 413, and read the unexecuted task node information from the predetermined storage unit 50.

[0091] The node cache module 102 is used to cache the initial scheduling command rbsched or task node information (sched cmd) received by the information receiving module 101. In this embodiment, the node cache module 102 includes a first storage area 1021 and a second storage area 1022. The first storage area 1021 is used to store the control information of the task node, and the second storage area 1022 is used to store the information of the task node. The control information of the task node may include information such as the identification and status information of the task node (for example, waiting for execution, executing, suspending execution, completed, etc.). The information of the task node stored in the second storage area 1022 includes information such as the identification and pointer node of the task node.

[0092] In an optional implementation, the first storage area 1021 can be a table implemented based on at least one register. The second storage area 1022 can be implemented based on SRAM (static random access memory). SRAM is a fast type of memory with low latency and high bandwidth, suitable for caching and high-speed data buffering. It should be understood that this embodiment does not limit the storage implementation form of the first storage area 1021 and the second storage area.

[0093] The task parsing module 103 is used to read the control information and task node information of the task node from the first storage area 1021 and the second storage area 1022 in the node cache module 102, determine whether the task node is the current executable node, and when the task node is the current executable node and carries the task command task, send it to the second engine 413. When the task node is an executable trunk node, a corresponding task read request is generated based on the node pointer of the trunk node to read the task node pointed to by the trunk node from the predetermined storage unit 50. The task parsing module 73 is used to send a task read request req3 to the predetermined storage unit 50 based on the node pointer of the task node (the task node or trunk node that has completed the task command), so that the predetermined storage unit 50 generates a response message rsq3 according to the task read request req3, and feeds back the response message rsq3 to the information receiving module 101. The response message rsq3 includes the unexecuted task node information pointed to by the node pointer. The specific workflow and Figure 7-Figure 9 The embodiments shown are similar and will not be described again here.

[0094] The first engine of the embodiment of the present invention stores the control information and task node information of the task node in the first storage area and the second storage area respectively, thereby improving the information access efficiency and further improving the task scheduling efficiency of the task node.

[0095] Further, if Figure 4 As shown, the second engine 413 is in communication with the first engine 412 and the execution engine 60. The second engine 413 is used to cache the executable task node information received from the first engine 412 and send the executable task node to the execution engine 60 for processing. Optionally, the second engine 413 is a track engine that is used to track the task execution status of each task node in parallel.

[0096] In an optional implementation, the second engine 413 includes k (k ≥ 1) cache locations (entries), each of which caches information about a task node. The number of cache locations in the second engine 413 can be determined based on the physical resources available in a specific application, and this embodiment does not limit this.

[0097] Furthermore, when the second engine 413 receives the executable task node sent by the first engine 412, it caches the executable task node in a certain cache location and sends the task command (task) carried by the executable task node to the execution engine 60 for execution. When the second engine 413 receives a task execution completion message returned by the execution engine 60, the second engine 413 updates the task node information in the corresponding cache location and returns the updated task execution completion task node information to the first engine 412 so that the first engine 412 can continue to execute. The execution process of the first engine 412 after receiving the task execution completion task node information can be referred to. Figure 7-Figure 9 The embodiments shown are not described in detail here.

[0098] Figure 11 This is a schematic diagram of the structure of a second engine according to an embodiment of the present utility model. Figure 11 As shown, the second engine 413 includes a first task cache module 111 and a second task cache module 112 . The first task cache module 111 and the second task cache module 112 are both in communication with the first engine 412 and the execution engine 60 .

[0099] The first task cache module 111 is configured to receive task execution commands corresponding to task nodes sent by the first engine 412. Optionally, the first task cache module 111 is implemented using a FIFO queue, such as an issue FIFO. The first task cache module 111 is configured to cache the task execution commands in a queue and send the task execution commands to the execution engine 60 for execution.

[0100] The second task cache module 112 is used to cache and update the received task node information. The second task cache module 112 is used to cache task node information, such as task dependency, task execution status and other information. The second task cache module 112 receives the dependency information corresponding to the task node sent by the first engine 412, and receives the task execution completion message returned by the execution engine 60, updates the task execution status information of the task node, and feeds back the updated executed task node information to the first engine 412 so that the first engine 412 can continue to execute. The execution process of the first engine 412 after receiving the task node information of the task execution completion can be referred to. Figure 7-Figure 9 The embodiments shown are not described in detail here.

[0101] In an embodiment of the present invention, the capacity of the second engine 413 is k, that is, it can track a maximum of k tasks simultaneously, that is, the maximum parallelism of the first cache unit 411 (also known as the ring buffer) is k, that is, k HW streams. Furthermore, the embodiment of the present invention maps the SW stream to these HW streams through a hardware and software interface (such as a device driver). As described above, when the number of SW streams does not exceed k, this embodiment can resolve task dependencies during parallel scheduling by defining tasks as scheduling commands (sched cmd) including task commands and dependencies.

[0102] Furthermore, when the number of SW streams exceeds k, the task scheduling system of the embodiment of the present invention may include multiple task scheduling modules. Thus, the embodiment can map tasks in multiple SW streams to different ringbuffers. At the same time, the embodiment of the present invention handles task dependencies across ringbuffers (i.e., across task scheduling modules) through a fence-semaphore mechanism (fence synchronization mechanism). That is, when there is a dependency between corresponding task nodes in different ring buffers, a specific value can be set. After the execution of the corresponding predecessor task node in one ring buffer is completed, the specific position is set to the specific value, and the task scheduling module corresponding to the other ring buffer scans the specific position until it finds that the specific position is set to the specific value, and determines that the task node that depends on the predecessor task node can be executed.

[0103] Furthermore, when all ring buffers are exhausted, this embodiment can introduce a false dependency to map different SW streams to the same HW stream. Figure 5 As shown, if all ringbuffers are exhausted, stream2 and stream1 can be mapped to the same HW stream. Specifically, a false dependency is created between task3 and task5, so that after task3 completes, task5 is read based on this false dependency to achieve task scheduling. It should be understood that in a false dependency, the execution of the subsequent task node does not depend on the execution result of the predecessor node; it is only used to facilitate task scheduling.

[0104] Therefore, the task scheduling system of this embodiment implements a multi-level task scheduling mechanism, which improves the task scheduling efficiency while ensuring the task scheduling reliability.

[0105] In an optional implementation, for known graph structures (such as cuda graphs), there is no need to set the Aux-Sched cmd introduced to implement dynamic submission (that is, it is only used as a processing dependency flow to nodes that do not carry tasks). At the same time, for known graph structures, the command buffer of the entire graph structure can be set directly on the device memory to shorten the memory access distance and further improve the task scheduling efficiency. Furthermore, for known graph structures, subsequent nodes can be prefetched when reading the preceding node to further improve access efficiency, thereby improving task scheduling efficiency.

[0106] The task scheduling system of the embodiment of the present utility model includes at least one task scheduling module, and the task scheduling module includes a first cache unit for caching an initial scheduling command, a first engine for storing information of at least one task node corresponding to the initial scheduling command, and a second engine for caching information of executable task nodes received from the first engine and sending the executable task nodes to the execution engine for processing. The initial scheduling command is used to trigger at least one task, and the information of the task nodes includes the dependency relationship of the task nodes. Thus, the task scheduling system of the embodiment of the present utility model can improve the parallelism of a single first cache unit based on the dependency relationship between the initial scheduling command and the task node through the first engine and the second engine, and avoid mutual blocking of different task commands when the task command can be scheduled for execution when it can be executed, thereby improving the task scheduling efficiency.

[0107] Figure 12 This is a flowchart of the task scheduling method of the embodiment of the utility model. Figure 12 As shown, the task scheduling method of the embodiment of the utility model includes the following steps:

[0108] Step S110, read at least one initial scheduling command from the first cache unit. The initial scheduling command is used to trigger at least one task. Optionally, the present embodiment may write each initial scheduling command (rbsched) into the first cache unit through a software and hardware interface (such as a device driver, etc.). Optionally, the initial scheduling command in the present embodiment may be determined based on the dependency relationship between tasks. Further optionally, there may or may not be a dependency relationship between tasks triggered by different initial scheduling commands. Thus, the present embodiment may write at least one initial scheduling command into the first cache unit through a software and hardware interface, so that the first engine traverses the graph structure in the predetermined storage unit by reading the initial scheduling command in the first cache unit.

[0109] Step S120: traverse the corresponding task node tree according to the initial scheduling command, and cache at least one task node information in the task node tree in the corresponding cache partition, wherein the task node tree includes multiple task nodes with dependency relationships.

[0110] In an optional implementation, the task node information cached by the cache partition includes root node information, leaf node information, and / or backbone node information, wherein the root node information is the node information corresponding to the initial scheduling command or the executed task node information.

[0111] In an optional implementation, this embodiment applies for a corresponding cache partition in response to an initial scheduling command or a task node traversed from a corresponding task node tree, and caches the initial scheduling command or the traversed task node as a root node in the corresponding cache partition. In another optional implementation, this embodiment responds to task node information in a cache partition indicating that a task has been executed, traverses the corresponding task node tree according to the dependency relationship of the executed task nodes, obtains the corresponding task node information from the task node tree, and updates the cache partition.

[0112] Step S130: parse the task node information to obtain executable task nodes.

[0113] In an optional implementation, this embodiment can determine the root node applied to the cache partition as an executable task node. Further optionally, this embodiment can also determine the leaf node carrying the task command and the dependency value of 0 as an executable task node. The dependency value is used to characterize the number of unexecuted task nodes that the corresponding task node depends on. Further optionally, this embodiment can also determine the trunk node whose branch number is less than or equal to the idle parameter in the cache partition as the executable node. The idle parameter is determined based on the idle position in the cache partition. Further optionally, the idle parameter can be equal to the number of idle positions in the corresponding cache partition + 1. The trunk node is executed to generate a task read request for accessing a predetermined storage unit, thereby reading the corresponding task node from the predetermined storage unit.

[0114] In an optional implementation, in response to the number of branches of the trunk node being greater than the corresponding idle parameter, this embodiment creates an empty task node corresponding to the trunk node, and determines the empty task node as an executable task node. Furthermore, in response to the cache partition including multiple trunk nodes and the number of branches of the trunk node being greater than the idle parameter, this embodiment creates an empty task node corresponding to at least one trunk node, and determines the empty task node as an executable task node. The empty task node points to the corresponding trunk node. Thus, this embodiment can apply for a new cache partition as the root node (root) after the empty task node is executed, so as to continue processing the original trunk node based on the new cache partition. It should be understood that at this time, a new task node tree is formed with the empty task node as the root node.

[0115] In this embodiment, the first engine in the task scheduling system in the above embodiment executes the traversal of the task node tree and the determination of the executable task nodes in steps S120 and S130. The specific workflow can be referred to above. Figure 7-10 The illustrated embodiment will not be described in detail here.

[0116] Step S140: dispatching the executable task node to the execution engine for execution.

[0117] In this embodiment, the second engine in the task scheduling system in the above embodiment executes step S140. The specific workflow can be referred to above. Figure 10 The illustrated embodiment will not be described in detail here.

[0118] The embodiment of the present utility model reads at least one initial scheduling command from the first cache unit, and traverses the corresponding task node tree according to the initial scheduling command, caches at least one task node information in the task node tree in the corresponding cache partition, parses the task node information, obtains executable task nodes, and dispatches the executable task nodes to the execution engine for execution. The initial scheduling command is used to trigger at least one task, and the task node tree includes a plurality of task nodes with dependencies. Thus, this embodiment can improve the parallelism of a single first cache unit based on the dependency between the initial scheduling command and the task node, and avoids mutual blocking of different task commands when the task command can be scheduled for execution when it can be executed, thereby improving the task scheduling efficiency.

[0119] Figure 13 Schematic diagram of the task scheduling device of the embodiment of the present utility model. Figure 13 As shown, the task scheduling device 130 of the embodiment of the present invention includes a first reading unit 131 , a traversal unit 132 , a parsing unit 133 and a dispatching unit 134 .

[0120] The first reading unit 131 is configured to read at least one initial scheduling command from the first cache unit, and the initial scheduling command is used to trigger at least one task. The traversal unit 132 is configured to traverse the corresponding task node tree according to the initial scheduling command, and cache at least one task node information in the task node tree in the corresponding cache partition, and the task node tree includes multiple task nodes with dependencies. The parsing unit 133 is configured to parse the task node information and obtain an executable task node. The dispatching unit 134 is configured to dispatch the executable task node to the execution engine for execution.

[0121] In an optional implementation, the task node information cached by the cache partition includes root node information, leaf node information, and / or trunk node information, and the root node information is the node information corresponding to the initial scheduling command or the executed task node information.

[0122] In an optional implementation, the traversal unit 132 is further configured to execute: in response to the initial scheduling command or the task node traversed from the task node tree, applying for a corresponding cache partition, caching the initial scheduling command or the traversed task node as a root node to the corresponding cache partition.

[0123] In an optional implementation, the traversal unit 132 is further configured to perform: in response to the task node information in the cache partition representing that the task has been executed, traverse the corresponding task node tree according to the dependency relationship of the executed task node, obtain the corresponding task node information from the task node tree and update the cache partition.

[0124] In an optional implementation, the parsing unit 133 is further configured to execute: determining the root node applied to the cache partition as the executable task node; and / or determining the leaf node carrying the task command and the dependency value of 0 as the executable task node, the dependency value is used to characterize the number of unexecuted task nodes on which the corresponding task node depends; and / or determining the trunk node whose branch number is less than or equal to the idle parameter in the cache partition as the executable node, the idle parameter is determined based on the idle position in the cache partition.

[0125] In an optional implementation, the parsing unit 133 is further configured to execute: in response to the cache partition including multiple trunk nodes and the number of branches of the trunk node being greater than the idle parameter, create at least one empty task node corresponding to the trunk node, the empty task node points to the corresponding trunk node, and determine the empty task node as the executable task node.

[0126] The embodiment of the present utility model reads at least one initial scheduling command from the first cache unit, and traverses the corresponding task node tree according to the initial scheduling command, caches at least one task node information in the task node tree in the corresponding cache partition, parses the task node information, obtains executable task nodes, and dispatches the executable task nodes to the execution engine for execution. The initial scheduling command is used to trigger at least one task, and the task node tree includes a plurality of task nodes with dependencies. Thus, this embodiment can improve the parallelism of a single first cache unit based on the dependency between the initial scheduling command and the task node, and avoids mutual blocking of different task commands when the task command can be scheduled for execution when it can be executed, thereby improving the task scheduling efficiency.

[0127] Figure 14 Schematic diagram of an electronic device according to an embodiment of the present utility model. In this embodiment, the electronic device 14 includes a server, a terminal, etc. Figure 14 As shown, the electronic device 14 includes: at least one processor 141; a memory 142 communicatively connected to at least one processor 141; and a communication component 143 communicatively connected to a scanning device, wherein the communication component 143 receives and sends data under the control of the processor 141; wherein the memory 142 stores instructions that can be executed by at least one processor 141, and the instructions are executed by at least one processor 141 using the task scheduling system in the above embodiment to implement the above task scheduling method.

[0128] Specifically, the electronic device includes: one or more processors 141 and a memory 142, Figure 14 In the example, a processor 141 is used. Optionally, the processor 141 may be a computing processor such as a GPU or a GPGPU. The processor 141 and the memory 142 may be connected via a bus or other means. Figure 14 In the example above, a bus connection is used. Memory 142, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules. Processor 141 executes the non-volatile software programs, instructions, and modules stored in memory 142 to execute various functional applications and data processing of the device, thereby implementing the aforementioned task scheduling method.

[0129] The memory 142 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store a list of options, etc. In addition, the memory 142 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 142 may optionally include a memory remotely located relative to the processor 141, and these remote memories may be connected to an external device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0130] One or more modules are stored in the memory 142 , and when executed by one or more processors 141 , perform the task scheduling method in any of the above method embodiments.

[0131] The above-mentioned product can execute the method provided in the embodiment of this application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of this application.

[0132] The embodiment of the present utility model reads at least one initial scheduling command from the first cache unit, and traverses the corresponding task node tree according to the initial scheduling command, caches at least one task node information in the task node tree in the corresponding cache partition, parses the task node information, obtains executable task nodes, and dispatches the executable task nodes to the execution engine for execution. The initial scheduling command is used to trigger at least one task, and the task node tree includes a plurality of task nodes with dependencies. Thus, this embodiment can improve the parallelism of a single first cache unit based on the dependency between the initial scheduling command and the task node, and avoids mutual blocking of different task commands when the task command can be scheduled for execution when it can be executed, thereby improving the task scheduling efficiency.

[0133] Another embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program, wherein the computer-readable program is used for enabling a computer to execute part or all of the above method embodiments.

[0134] That is, those skilled in the art will understand that all or part of the steps in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a program, which is stored in a storage medium and includes a number of instructions for causing a device (which may be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the methods described in the embodiments of the present application. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., various media that can store program code.

[0135] The foregoing is merely a preferred embodiment of the present application and is not intended to limit the present application. Persons skilled in the art will readily appreciate that various modifications and variations are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application are intended to be within the scope of protection of the present application.

Claims

1. A task scheduling system, characterized in that: The task scheduling system includes at least one task scheduling module, and the task scheduling module includes: A first cache unit, configured to cache an initial scheduling command, where the initial scheduling command is used to trigger at least one task; a first engine, communicatively connected to the first cache unit, configured to store information of at least one task node corresponding to the initial scheduling command, the information of the task node including dependencies of the task nodes, the first engine being a hardware component, comprising a node cache module, the node cache module configured to cache the initial scheduling command or task node information, the node cache module comprising a plurality of cache partitions, the cache partitions configured to cache information of at least one task node in a corresponding task node tree; The second engine is communicatively connected to the first engine, and the second engine includes multiple cache locations, each cache location is used to cache executable task node information received from the first engine, and send the executable task node to the execution engine for processing.

2. The system according to claim 1, wherein: The first cache unit includes: A memory access module is connected to a predetermined storage unit for sending a task scheduling request to the predetermined storage unit according to the configuration information, wherein the predetermined storage unit is used to store task node information corresponding to the task to be executed; a command caching module, communicatively connected to the predetermined storage unit, and configured to cache at least one initial scheduling command fed back by the predetermined storage unit; A command decoder is communicatively connected to the command cache module and the first engine, and is configured to read the initial scheduling command from the command cache module and send the command to the first engine.

3. The system according to claim 1 or 2, characterized in that The first cache unit is a linear ring cache unit.

4. The system according to claim 1, wherein: The first engine further includes: an information receiving module, communicatively connected to the first cache unit, the second engine, and the predetermined storage unit, configured to receive the initial scheduling command sent by the first cache unit, the executed task node information fed back by the second engine, and read the unexecuted task node information from the predetermined storage unit; A task parsing module is communicatively connected to the node cache module and the second engine, and is used to obtain unexecuted task node information from the node cache module and send the task node information to the second engine when the task node information includes a currently executable task execution command.

5. The system according to claim 1, wherein: The node cache module includes: The first storage area is used to store control information of the task node; The second storage area is used to store task node information; The first storage area is implemented based on at least one register, and the second storage area is implemented based on a static random access memory.

6. The system according to claim 1, wherein: The second engine includes: A first task cache module is connected to the first engine and the execution engine for receiving a task execution command corresponding to a task node sent by the first engine; The second task cache module is connected to the first engine and the execution engine for caching and updating the received task node information.

7. An electronic device comprising a memory and a processor, characterized in that: The memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are used by the processor to perform task scheduling using the task scheduling system according to any one of claims 1 to 6.

Images