Task scheduling method and device, storage medium and electronic equipment

Abstract

The invention provides a task scheduling method and device, a storage medium and electronic device.The method is applied to a runtime library of a host and comprises the steps that in response to a received calculation task, a kernel driver is called to obtain performance data of at least two core particles, and a scheduling score corresponding to each core particle is determined according to the performance data; scheduling the calculation task to the corresponding core particle for execution based on the scheduling score; the scheduling score is determined on the basis of the performance data of the core particles, task scheduling is executed, accurate adaptation of the calculation task and the core particles is achieved, and the task execution efficiency and the resource utilization rate under the multi-core-particle architecture are effectively improved.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a task scheduling method and apparatus, storage medium and electronic device. Background Technology

[0002] As the number of parameters in large artificial intelligence (AI) models increases, higher and higher requirements are placed on the computing power density and memory bandwidth of chips. AI chips such as graphics processing units (GPUs), tensor processing units (NPUs), and neural network processing units (TPUs) widely adopt homogeneous multi-die architectures to break through the physical and cost limitations of traditional single-chip integration.

[0003] In related technologies, a complete computational process from task distribution to result return is constructed through collaborative operations involving die encapsulation, inter-die interconnection, and host communication. In the task scheduling method, the main die (first die) acts as the scheduling hub. Specifically, the host sends computational tasks to the first die, which then distributes the tasks to other dies and the first die via a task scheduler. Once the other dies and the first die complete their tasks, they notify the host, thus completing the entire scheduling process. However, because the host relies on the first die for centralized scheduling, if the first die's scheduling function fails, the system becomes unavailable. Summary of the Invention

[0004] This disclosure provides a task scheduling method, apparatus, storage medium, and electronic device to solve problems in related technologies. By determining the scheduling score based on the performance data of the core and executing task scheduling, it achieves accurate matching between computing tasks and cores, effectively improving task execution efficiency and resource utilization under a multi-core architecture.

[0005] According to a first aspect of this disclosure, a task scheduling method is provided, comprising: In response to the received computing task, the kernel driver is invoked to obtain the performance data of at least two cores, and the scheduling score corresponding to each core is determined based on the performance data. The computational task is scheduled to the corresponding core for execution based on the scheduling score.

[0006] In some embodiments of this disclosure, the step of responding to a received computing task by invoking a kernel driver to obtain performance data for at least two cores and determining a scheduling score for each core based on the performance data includes: In response to a received computing task, determine the load level of the computing task; Based on the load level, the kernel driver is invoked to collect the performance data corresponding to the at least two cores respectively; Based on the performance data, a preset weighted algorithm is used to calculate the scheduling score of each core.

[0007] In some embodiments of this disclosure, the step of calling the kernel driver to obtain performance data from at least two chips includes at least one of the following steps: The link latency between the host and the chip is determined by sending and receiving link latency requests between the host and the chip through the kernel driver; The kernel driver performs periodic polling to obtain the queue depth of the at least two cores, and determines the load information based on the queue depth. The kernel driver periodically polls the performance monitoring units of each of the at least two cores to obtain the core utilization rate. The performance data includes at least one of the link latency between the host and the chip, the load information of the chip, and the utilization rate of the chip.

[0008] In some embodiments of this disclosure, scheduling the computation task to the corresponding chip based on the scheduling score includes: The scheduling score of each core particle is normalized to obtain the normalized scheduling score. Determine the scheduling weight corresponding to the normalized scheduling score; The total number of subtasks after the computation task is split is multiplied by the scheduling weight of each core particle and rounded down to determine the number of subtasks corresponding to each core particle. The corresponding number of subtasks are scheduled to be executed by the corresponding core particles.

[0009] In some embodiments of this disclosure, after multiplying the total number of subtasks after splitting the computation task with the scheduling weight of each core and rounding down to determine the integer number of subtasks corresponding to each core, the process includes: The number of unassigned subtasks is determined based on the sum of the number of subtasks corresponding to each core and the total number of subtasks. The number of unassigned subtasks is allocated to the core with the highest scheduling weight.

[0010] In some embodiments of this disclosure, determining the load level of the computing task in response to a received computing task includes: The computation task is passed through a unified adaptation layer, and the task characteristics of the computation task are obtained by parsing the unified adaptation layer; wherein, the task characteristics include at least one of thread dimension, task size and number of tasks; Based on the task characteristics, the computing tasks are divided into different load levels.

[0011] In some embodiments of this disclosure, the step of passing the computing task through a unified adaptation layer and resolving the task characteristics of the computing task based on the unified adaptation layer includes: A management queue for the computing tasks is constructed; wherein the management queue is used to store and manage the computing tasks; The unified adaptation layer retrieves the computing task from the management queue and parses the task characteristics of the computing task.

[0012] In some embodiments of this disclosure, after determining the scheduling score corresponding to each core based on the performance data, the method further includes: Based on the load level, determine whether the computing task needs to be split. If it is determined that the computing task needs to be split, the computing task shall be divided into at least two sub-tasks; The step of scheduling the computation task to the corresponding core based on the scheduling score includes: The computation task is scheduled to be executed in an idle core corresponding to the computation task based on the scheduling score.

[0013] According to a second aspect of this disclosure, a task scheduling apparatus is provided, comprising: The first determining unit is used to respond to the received computing task by calling the kernel driver to obtain the performance data of at least two cores and to determine the scheduling score corresponding to each core based on the performance data. The first scheduling unit is used to schedule the computing task to the corresponding core for execution based on the scheduling score.

[0014] In some embodiments of this disclosure, the first determining unit includes: The first determining module is used to determine the load level of the received computing task in response to the computing task. The acquisition module is used to call the kernel driver to acquire the performance data corresponding to the at least two cores based on the load level. The calculation module is used to calculate the scheduling score of each core particle based on the performance data using a preset weighted algorithm.

[0015] In some embodiments of this disclosure, the acquisition module includes: The first determining submodule is used to determine the link latency between the host and the chip by sending and receiving link latency requests between the host and the chip through the kernel driver; The second determining submodule is used to periodically poll through the kernel driver to obtain the queue depth of the at least two cores, and determine the load information based on the queue depth; The acquisition submodule is used to periodically poll the performance monitoring units of the at least two cores through the kernel driver to obtain the utilization rate of the cores; The performance data includes at least one of the link latency between the host and the chip, the load information of the chip, and the utilization rate of the chip.

[0016] In some embodiments of this disclosure, the first scheduling unit includes: The processing module is used to normalize the scheduling score of each core to obtain a normalized scheduling score. The second determining module is used to determine the scheduling weight corresponding to the normalized scheduling score; The third determining module is used to multiply the total number of subtasks after the calculation task is split by the scheduling weight of each core particle and round down to determine the number of subtasks corresponding to each core particle. The first scheduling module is used to schedule the corresponding number of subtasks to the corresponding cores for execution.

[0017] Some embodiments of this disclosure include: The fourth determining module is used to determine the number of unassigned subtasks based on the sum of the number of subtasks corresponding to each core and the total number of subtasks after the calculation task is split by the third determining module, by multiplying the total number of subtasks by the scheduling weight of each core and rounding down to determine the number of subtasks corresponding to each core and the total number of subtasks. The allocation module is used to allocate the number of unallocated subtasks to the core with the highest scheduling weight.

[0018] In some embodiments of this disclosure, the first determining module includes: The parsing submodule is used to pass the computing task through a unified adaptation layer and parse the task characteristics of the computing task according to the unified adaptation layer; wherein, the task characteristics include at least one of thread dimension, task size and number of tasks; The partitioning submodule is used to divide the computing task into different load levels based on the task characteristics.

[0019] In some embodiments of this disclosure, the parsing submodule is further configured to: A management queue for the computing tasks is constructed; wherein the management queue is used to store and manage the computing tasks; The unified adaptation layer retrieves the computing task from the management queue and parses the task characteristics of the computing task.

[0020] In some embodiments of this disclosure, the apparatus further includes: The judgment unit is used to determine whether the computing task needs to be split based on the load level after the first determining unit determines the scheduling score corresponding to each core based on the performance data. A partitioning unit is used to divide the computing task into at least two subtasks when it is determined that the computing task needs to be split. The first scheduling unit includes: The second scheduling module is used to schedule the computing task to the idle core corresponding to the computing task for execution based on the scheduling score.

[0021] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect embodiment.

[0022] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect of the present disclosure.

[0023] In summary, according to the task scheduling method, apparatus, storage medium, and electronic device provided in this disclosure, the method includes: in response to a received computing task, determining the load level of the computing task; based on the load level, determining whether the computing task needs to be split; in response to the need to split the computing task, acquiring performance data of at least two dies, and determining the scheduling score corresponding to each die based on the performance data; dividing the computing task into at least two subtasks, and scheduling all subtasks to the corresponding dies for execution based on the scheduling score; determining the at least two subtasks of the computing task based on the load level; determining the scheduling score of each die through the performance data of at least two dies; and executing the corresponding at least two subtasks based on the scheduling score of each die. This improves the load balancing capability of computing tasks in a multi-die architecture and enhances resource utilization.

[0024] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0025] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A flowchart illustrating a task scheduling method provided in an embodiment of this disclosure; Figure 2 A schematic diagram illustrating an application scenario of a task scheduling method provided in this embodiment of the disclosure; Figure 3 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 4 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 5 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 6 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 7 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 8 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 9 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 10 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 11 A flowchart illustrating another task scheduling method provided in an embodiment of this disclosure; Figure 12 A schematic diagram of the structure of a task scheduling device provided in an embodiment of this disclosure; Figure 13 A schematic diagram of the structure of another task scheduling device provided in an embodiment of this disclosure; Figure 14 A schematic block diagram of an example electronic device provided for embodiments of this disclosure. Detailed Implementation

[0026] Embodiments of this disclosure are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0027] As the number of parameters in large artificial intelligence (AI) models increases, higher and higher requirements are placed on the computing power density and memory bandwidth of chips. AI chips such as graphics processing units (GPUs), tensor processing units (NPUs), and neural network processing units (TPUs) widely adopt homogeneous multi-die architectures to break through the physical and cost limitations of traditional single-chip integration.

[0028] In related technologies, a complete computational process from task distribution to result return is constructed through collaborative operations involving die encapsulation, inter-die interconnection, and host communication. In the task scheduling method, the main die (first die) acts as the scheduling hub. Specifically, the host sends computational tasks to the first die, which then distributes the tasks to other dies and the first die via a task scheduler. Once the other dies and the first die complete their tasks, they notify the host, thus completing the entire scheduling process. However, because the host relies on the first die for centralized scheduling, if the first die's scheduling function fails, the system becomes unavailable.

[0029] Therefore, in order to solve the problems existing in the related technologies, this disclosure proposes a task scheduling method, which includes: in response to a received computing task, determining the load level of the computing task; based on the load level, determining whether the computing task needs to be split; in response to the computing task needing to be split, obtaining performance data of at least two dies, and determining the scheduling score corresponding to each die based on the performance data; dividing the computing task into at least two subtasks, and scheduling all subtasks to the corresponding dies for execution based on the scheduling score; determining the at least two subtasks of the computing task based on the load level; determining the scheduling score of each die through the performance data of at least two dies; and executing the corresponding at least two subtasks based on the scheduling score of each die. This improves the load balancing capability of computing tasks in a multi-die architecture and improves resource utilization.

[0030] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0031] In each of the disclosed embodiments, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. In this disclosure, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun following the article can be understood as either a singular or a plural expression.

[0032] In some embodiments, the terms “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “if…”, “if…”, etc., can be used interchangeably. In some embodiments, the terms “greater than,” “greater than or equal to,” “not less than,” “more than,” “more than or equal to,” “not less than,” “higher than,” “higher than or equal to,” “not lower than,” and “above” can be used interchangeably, as can the terms “less than,” “less than or equal to,” “not greater than,” “less than,” “less than or equal to,” “not more than,” “lower than,” “lower than or equal to,” “not higher than,” and “below”. The prefixes such as "first" and "second" in the embodiments of this disclosure are only for distinguishing different descriptive objects and do not constitute restrictions on the position, order, priority, number or content of the descriptive objects. For the description of the descriptive objects, please refer to the description in the claims or the context of the embodiments. The use of prefixes should not constitute unnecessary restrictions.

[0033] In the embodiments disclosed herein, "multiple" refers to two or more. In the embodiments disclosed herein, terms such as “import”, “input”, and “read in” can be used interchangeably.

[0034] In some embodiments, devices, etc., can be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. Terms such as “device”, “equipment”, “circuit”, “network element”, “node”, “function”, “unit”, “section”, “system”, “network”, “chip”, “chip system”, “entity”, and “subject” can be used interchangeably.

[0035] Figure 1 This is a flowchart illustrating a task scheduling method provided in an embodiment of the present disclosure, as shown below. Figure 1 As shown, the scheduling method for this task includes steps 101-102.

[0036] Step 101: In response to the received computing task, the kernel driver is invoked to obtain the performance data of at least two cores, and the scheduling score corresponding to each core is determined based on the performance data.

[0037] In some embodiments, the host runtime library, in response to a received computational task (such as a kernel task submitted by a deep learning framework), triggers scheduling logic: It calls the kernel driver to selectively acquire performance data from at least two kernels in the system (e.g., kernels Die1 and Die2); it uses the kernel driver to send and receive link latency requests between the host and the kernels to determine the link latency between the host and Die1 (e.g., 1.8ms) and with Die2 (e.g., 2.6ms); it uses the kernel driver to periodically poll to acquire load information (e.g., queue depth 1) and utilization (e.g., 38%) for Die1, and load information (e.g., queue depth 2) and utilization (e.g., 55%) for Die2; based on the acquired performance data, the runtime library calculates the scheduling score corresponding to each kernel according to preset rules, for example, the scheduling score for Die1 (e.g., 0.31) and the scheduling score for Die2 (e.g., 0.53). It should be noted that the above examples are merely illustrative and do not limit the specific content.

[0038] By directly obtaining the performance data of at least two kernel particles through kernel driver calls, the real-time and reliability of scheduling criteria are ensured, avoiding blind scheduling without data support. The performance differences of kernel particles are quantified into directly comparable scheduling scores, providing a clear and objective decision-making benchmark for accurate task allocation.

[0039] Step 102: Schedule the computing task to the corresponding core for execution based on the scheduling score.

[0040] In some embodiments, based on a determined scheduling score, the host runtime library schedules the computation task to the corresponding die for execution. Since the scheduling score of Die1 (e.g., 0.31) is lower than that of Die2 (e.g., 0.53), it indicates that Die1 is more adaptable to the computation task. The runtime library issues task execution instructions and computation tasks to Die1 through the kernel driver. After receiving the task execution instructions and computation tasks, Die1 performs the operation and, after the operation is completed, feeds back the result to the host runtime library through the communication link.

[0041] One feasible approach is to divide the computation task into at least two subtasks, and then schedule all the subtasks to the appropriate dies for execution based on the difference in scheduling scores for each die.

[0042] The scheduling score enables precise matching of computing tasks with chip performance, effectively avoiding resource mismatch issues such as idle high-performance chips and overloaded low-performance chips. The scheduling process relies on direct interaction between the host runtime library and the kernel driver, which is simple and without redundancy, ensuring that computing tasks are quickly distributed and executed, adapting to general computing task processing scenarios, and significantly improving overall task execution efficiency.

[0043] In some embodiments, the Host communicates with the first Die via a high-speed bus, and each Die communicates with each other via Die-to-Die. The Host can also communicate with other Dies besides the first Die via Die-to-Die.

[0044] This disclosure applies to AI system architectures and scheduling methods, particularly to load and task scheduling methods for homogeneous multi-die architectures. It can be applied to fields such as AI inference, training, and high-performance computing. Figure 2 The diagram illustrates an application scenario of a task scheduling method provided in this embodiment. This embodiment applies to an AI runtime library, adding task scheduling functionality to it. This allows for task scheduling of computational tasks for each operator library (operator library 1, operator library 2, and operator library 3). The kernel driver on the host and the firmware on the device work together to implement the entire task scheduling process. Through multi-die and task scheduling, the maximum utilization of computing resources is achieved.

[0045] In summary, the task scheduling method provided in this disclosure includes: in response to a received computing task, determining the load level of the computing task; based on the load level, determining whether the computing task needs to be split; in response to the need to split the computing task, obtaining performance data of at least two dies, and determining the scheduling score corresponding to each die based on the performance data; dividing the computing task into at least two subtasks, and scheduling all subtasks to the corresponding dies for execution based on the scheduling score; determining the at least two subtasks of the computing task based on the load level; determining the scheduling score of each die based on the performance data of at least two dies; and executing the corresponding at least two subtasks based on the scheduling score of each die. This improves the load balancing capability of computing tasks in a multi-die architecture and enhances resource utilization.

[0046] Figure 3 A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 1 The illustrated embodiment further explains step 101. Figure 3 This may include the following steps: Step 201: In response to the received computing task, determine the load level of the computing task.

[0047] In some embodiments, the host runtime library, in response to a received computation task (such as a kernel task submitted by a deep learning framework), first parses metadata from the launchKernel API of the computation task. The metadata includes, but is not limited to, thread dimension size (e.g., (256,256,1)), tensor data size (e.g., 1GB), and number of blocks (e.g., 128). Then, a heuristic evaluation method is used to quantitatively analyze the computational load and resource requirements of the task in combination with the metadata, and finally the load level of the computation task (e.g., low small, medium, high large, etc.) is determined.

[0048] Step 202: Based on the load level, call the kernel driver to collect the performance data corresponding to the at least two cores respectively.

[0049] In some embodiments, the kernel driver continuously collects performance data from at least two granules (such as granules Die1, Die2, and Die3) in the system and updates the performance data to the performance data warehouse in real time to complete the dynamic construction and maintenance of the performance data warehouse. The host runtime library queries the performance data warehouse and, based on the load level of the computing task, collects performance data from at least two granules (such as granules Die1, Die2, and Die3) by calling the kernel driver. The computing task dynamically adjusts the collection range and frequency according to its load level. The collected performance data is as follows: via the kernel... The driver sends and receives link latency requests to obtain the link latency between the host and Die1 (e.g., 1.2ms), Die2 (e.g., 1.9ms), and Die3 (e.g., 2.5ms). Through periodic polling by the kernel driver, the load information (queue depth 1) and utilization (e.g., 40%) of Die1, the load information (queue depth 2) and utilization (e.g., 60%) of Die2, and the load information (queue depth 3) and utilization (e.g., 75%) of Die3 are obtained, ensuring that the collected performance data accurately matches the execution requirements of computing tasks with different load levels.

[0050] To facilitate understanding of the workload levels of computational tasks, the following examples illustrate this: If the computational task is determined to be high-load (e.g., a task requiring the processing of 100,000 frames of images for object detection), select all active dies in the system (let's say Die1, Die2, and Die3, a total of 3), and increase the sampling frequency (e.g., sampling once every 10ms). If the computational task is low-load (e.g., a single-value summation task), then only the performance data of the 2 dies with the best performance in the last 3 scheduling iterations can be collected, and the sampling frequency can be reduced (e.g., sampling once every 100ms). It should be noted that the above is only an illustrative example and does not limit the specific content.

[0051] Step 203: Based on the performance data, calculate the scheduling score of each core using a preset weighted algorithm.

[0052] Based on performance data, the Host will use a preset weighted algorithm to calculate the scheduling score of each Die. The preset weighted algorithm performs a comprehensive calculation based on multiple different performance indicators (such as link latency between the Host and the Die, Die load information, Die utilization, etc.) to obtain the scheduling score of each Die.

[0053] To facilitate understanding, an example is given below: The performance metrics in the performance data are set as follows: Host-Die link latency (30%), Die load information (40%), and Die utilization (30%). Performance data for three dies (Die1, Die2, and Die3) are collected. Die1: Link latency is 10ms (equivalent to a score of 90 points, with shorter latency resulting in a higher score), load is 20% (equivalent to a score of 80 points, with lower load resulting in a higher score), and utilization is 30% (equivalent to a score of 70 points, with lower utilization resulting in a higher score). Die2: Link latency is 20ms (equivalent to a score of 70 points), load is 20% (equivalent to a score of 80 points, with lower load resulting in a higher utilization), and utilization is 30% (equivalent to a score of 70 points, with lower utilization resulting in a higher utilization). With a load of 50% (equivalent to a score of 50) and a utilization rate of 60% (equivalent to a score of 60), Die3 has a link latency of 15ms (equivalent to a score of 80), a load of 30% (equivalent to a score of 70), and a utilization rate of 50% (equivalent to a score of 65). The scheduling score for Die1 is 90×30%+80×40%+70×30%=27+32+21=80 points; the scheduling score for Die2 is 70×30%+50×40%+60×30%=21+20+18=59 points; and the scheduling score for Die3 is 80×30%+70×40%+65×30%=24+28+19.5=71.5 points. It should be noted that the above examples are for illustrative purposes only, and the specific numerical values ​​are not limited.

[0054] The above methods, through heuristic load level assessment based on meta-information, provide clear targeting for performance data collection, avoiding data redundancy caused by indiscriminate collection. By querying the chip performance data warehouse and combining it with the die benchmark data stored in the chip, the collection of performance data becomes more reference-based. Combined with load level-oriented collection of indicators such as link latency, queue depth, and utilization, the effectiveness and accuracy of scheduling criteria are ensured. A preset weighted algorithm is used to quantify multi-dimensional performance data into scheduling scores, realizing a comprehensive assessment of chip adaptability. The collaboration of these three aspects makes scheduling decisions more in line with task requirements and the actual state of the chip, significantly improving the execution efficiency and resource utilization of high-load tasks in a multi-chip architecture.

[0055] Figure 4 A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 3 The embodiment shown, Figure 4 This may include the following steps: Step 301: Determine the link latency between the host and the chip by sending and receiving link latency requests between the host and the chip through the kernel driver.

[0056] In some embodiments, when the host runtime library needs to collect performance data, it queries the performance data warehouse of each die and sends RTT request messages (i.e., link latency requests) to the dies (such as Die1, Die2, and Die3) through the kernel driver. After the die receives and returns an RTT response message, the kernel driver calculates the round-trip time of the message transmission and reception, and finally determines the link latency between the host and each die. For example, the link latency between the host and Die1 is 1.2ms, with Die2 it is 1.9ms, and with Die3 it is 2.5ms. It should be noted that the above examples are for illustrative purposes only and are not intended to limit the specific content.

[0057] Step 302: Periodically poll the kernel driver to obtain the queue depth of the at least two cores, and determine the load information based on the queue depth.

[0058] In some embodiments, the host runtime library, based on a preset polling period (e.g., 50ms / time), periodically polls the task execution queues of at least two kernels (e.g., Die1, Die2, Die3) in the system through the kernel driver to obtain the task execution queue length (i.e., queue depth) of each kernel. This queue depth reflects the number of kernel tasks currently queued in the kernel. The currently obtained queue depth is quantitatively analyzed; for example, Die1's queue depth is 1, Die2's queue depth is 2, and Die3's queue depth is 3. Finally, the load information of each kernel is determined based on the queue depth quantification result. It should be noted that the above examples are merely illustrative and do not limit the specific content.

[0059] Step 303: The kernel driver periodically polls the performance monitoring units of the at least two cores to obtain the core utilization rate; wherein the performance data includes at least one of the link latency between the host and the core, the load information of the core, and the utilization rate of the core.

[0060] In some embodiments, to obtain the computing resource occupancy status of the die particles, the host runtime library periodically polls the performance monitoring units (PMUs) integrated into at least two die particles (e.g., Die1, Die2, Die3) through the kernel driver at a preset period (e.g., 50ms / time). The performance monitoring units of the die particles statistically analyze data such as the runtime percentage of the computing components and instruction execution efficiency in real time. The kernel driver reads the raw data from the performance monitoring units and converts it into the utilization rate of the die particles. For example, the utilization rate of Die1 is 40%, Die2 is 60%, and Die3 is 75%. The core performance data includes three categories: link latency between the host and the die particles, load information of the die particles, and the utilization rate of the die particles. In actual scheduling, one or more types of data can be selected and combined according to the task type. It should be noted that the above examples are only illustrative and do not limit the specific content.

[0061] The above methods employ an RTT message exchange mechanism to collect link latency, ensuring the accuracy and verification basis of latency data. Periodic polling of queue depth determines load information, reflecting the pressure of accumulated computing tasks within the core. Utilization rate is collected based on the core's performance monitoring unit, ensuring the real-time nature and accuracy of resource usage data. This achieves comprehensive acquisition of multi-dimensional performance data, including link latency, load, and utilization rate, making task scheduling decisions more aligned with the actual performance status of the core and task requirements, thus improving the scheduling rationality and execution efficiency under a multi-core architecture.

[0062] Figure 5 A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 1 The embodiment shown, Figure 5 This may include the following steps: Step 401: Normalize the scheduling score of each core to obtain the normalized scheduling score.

[0063] In some embodiments, after determining the scheduling score of each die using a preset weighted algorithm, the host first normalizes the initial scheduling scores of all dies. After normalization, the scheduling score range of all dies is uniformly mapped to the [0,1] interval. The purpose is to eliminate the difference in scheduling scores under different computing scenarios and make the scheduling scores of different dies comparable. During the normalization process, the maximum scheduling score is selected from all normalized scheduling scores. This maximum scheduling score will be used as the benchmark for subsequent scheduling score conversion. By comparing the maximum scheduling score with the normalized scheduling scores of other dies, the adaptability differences between each die are amplified.

[0064] Step 402: Determine the scheduling weight corresponding to the normalized scheduling score.

[0065] In some embodiments, based on the normalized scheduling score, the calculation process is as follows: The base weight of each core is obtained by subtracting the normalized scheduling score of each core from the maximum normalized scheduling score. The base weights of all cores are then summed to obtain the total weight. Finally, the base weight of each core is divided by the total weight to obtain the proportional result of the scheduling weight of each core. The sum of the scheduling weights of all cores is 1. The lower the scheduling score of each core, the higher its base weight, and the lower its corresponding scheduling weight. It should be noted that the direct or inverse proportional relationship between scheduling score and scheduling weight is not limited and can be flexibly set according to actual scheduling needs.

[0066] As an effective approach, to avoid the inability to assign subtasks due to the base weight of the core being 0, a very small positive number, such as 0.01, is superimposed on the calculation result to ensure the effectiveness of the weight allocation.

[0067] Step 403: Multiply the total number of subtasks after the calculation task is split by the scheduling weight of each core and round down to determine the number of subtasks corresponding to each core.

[0068] After determining the scheduling weight of each Die, the Host will combine the total number of subtasks after the calculation task is split to determine the number of subtasks allocated to each Die. The total number of subtasks will be multiplied by the scheduling weight of each Die, and the result of the multiplication will be rounded down to the nearest integer, keeping only the integer part and discarding the decimal part, to determine the integer number of subtasks corresponding to each Die.

[0069] To facilitate understanding, the following example illustrates the concept: If a computational task is divided into 10 subtasks, and the chip contains 3 dies (Die1, Die2, and Die3), with Die1 having a scheduling weight of 0.21, Die2 having a scheduling weight of 0.35, and Die3 having a scheduling weight of 0.44, then the number of subtasks allocated to Die1 is 10 × 0.21 = 2, to Die2 is 10 × 0.35 = 3, and to Die3 is 10 × 0.44 = 4. It should be noted that the above example is merely illustrative and does not limit the specific implementation.

[0070] Ensure that the number of subtasks executed by each Die is an integer, which meets the actual needs of each Die (subtasks cannot be broken down into non-integer units). Keep the allocation results in line with the scheduling weight of each Die. The higher the weight of the Die, the more subtasks it will get after multiplication and rounding. This ensures that highly adaptable Dies can execute more computing tasks and promote efficient parallel processing of computing tasks.

[0071] Step 404: Schedule the corresponding number of subtasks to be executed by the corresponding cores.

[0072] The host schedules integer subtasks to the corresponding dies for execution based on the scheduling weight of each die. The scheduling logic is directly related to the weight. The higher the scheduling weight of a die, the more integer subtasks it receives and the more integer subtasks it is assigned. The lower the scheduling weight of a die, the fewer integer subtasks it receives and the fewer integer subtasks it is assigned. Integerization ensures that subtasks can be executed and avoids non-integer units of computation.

[0073] Figure 6 A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 5 The embodiment shown, Figure 6 This may include the following steps: Step 501: Determine the number of unassigned subtasks based on the sum of the number of subtasks corresponding to each core and the total number of subtasks.

[0074] Given that the number of integer subtasks and the total number of subtasks are already determined, if the number of integer subtasks is less than or equal to the number of computation tasks, the difference between the number of computation tasks and the number of integer subtasks is taken, and the difference is determined as the unassigned subtasks.

[0075] For example, if there are a total of 10 computational tasks, and the three dies are assigned 7, 2, and 0 integer subtasks respectively, the total number of integer subtasks is 9. In this case, there is one unassigned subtask. It should be noted that the above example is for illustrative purposes only and is not intended to limit the specific content.

[0076] This method identifies unassigned subtasks, ensuring that all subtasks are properly allocated to the Die for execution, avoiding omissions due to rounding operations, and thus guaranteeing the integrity of the computation task.

[0077] Step 502: Allocate the number of unassigned subtasks to the core with the highest scheduling weight.

[0078] The host schedules unassigned subtasks to the die with the highest scheduling weight for execution. The die with the highest scheduling weight is considered the best fit, and its subtask processing capability is superior to other dies. Scheduling unassigned subtasks to the die with the highest scheduling weight ensures that unassigned subtasks can quickly integrate into the parallel execution flow, thus preventing the host from missing computational tasks.

[0079] In some embodiments, such as Figure 7 The diagram shows a flowchart of another task scheduling method provided in this embodiment of the present disclosure. The management queue obtains the performance data of the Die through the Die performance acquisition module in the performance acquisition module, stores the performance data of the Die through the performance data warehouse, and according to the decision of the scheduling decision module in the Host on the allocation of computing tasks of the Die, the result of the decision is scheduled to each Die for execution through the task scheduling module in the Host.

[0080] Figure 8 A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 1 The illustrated embodiment further explains step 101. Figure 8 This may include the following steps: Step 601: The computing task is passed through a unified adaptation layer, and the task characteristics of the computing task are obtained by parsing the unified adaptation layer; wherein, the task characteristics include at least one of thread dimension, task size and number of tasks.

[0081] The computation task is parsed by the unified adaptation layer, which then obtains the task characteristics. The unified adaptation layer, as an intermediate module for standardization, transforms the computation task into task characteristic information that the host can recognize. Task characteristics include, but are not limited to, thread dimension, task size, and number of tasks. Among them, the thread dimension reflects the parallel execution capability of the computation task, the task size reflects the computational or data volume of the computation task, and the number of tasks reflects the total number of subtasks that the computation task can be divided into. By analyzing the task characteristics through the unified adaptation layer, the host can grasp the essential attributes and execution requirements of the computation task.

[0082] Step 602: Based on the task characteristics, the computing task is divided into different load levels.

[0083] Based on task characteristics, computational tasks are classified into different load levels. By integrating task characteristics such as thread count, task size, and number of tasks, the hardware resource requirements of computational tasks are assessed. For example, computational tasks with high thread count, large task size, and a large number of tasks are classified as high load levels, while tasks with low thread count and low computational load are classified as low load levels. It should be noted that the above examples are for illustrative purposes only and are not intended to limit the specific content.

[0084] By classifying computing tasks by load level, the host can intuitively distinguish the resource consumption characteristics and execution pressure of different computing tasks, and provide a clear basis for matching appropriate dies to computing tasks of different load levels (such as prioritizing the allocation of high-load computing tasks to dies with better performance).

[0085] Figure 9A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 1 The illustrated embodiment further explains step 104. Figure 9 This may include the following steps: Step 701: Construct a management queue for the computing tasks; wherein the management queue is used to store and manage the computing tasks.

[0086] Each Die is assigned a corresponding management queue. The management queue contains all the subtasks that the Die needs to execute. The management queue is used to manage the subtasks executed by each Die in an orderly manner. All subtasks enter the management queue of the corresponding Die in the order of assignment. Each Die processes the subtasks in the order of the management queue.

[0087] By constructing a management queue, it is ensured that all subtasks have a clear execution path, avoiding omissions in computation tasks. The host can keep track of the queuing status of each die in the current management queue, ensuring the orderliness and controllability of computation tasks during execution.

[0088] Step 702: Obtain the computing task from the management queue through the unified adaptation layer, and parse the task characteristics of the computing task.

[0089] As a component connecting the management queue and the task parsing module, the unified adaptation layer is capable of being compatible with multiple types of computational task formats and can achieve standardized acquisition and feature parsing of tasks. Assuming that the management queue stores three types of computational tasks to be processed according to the receiving time: Task A (image segmentation application), Task B (numerical simulation tool, marked with high priority), and Task C (natural language processing service), the unified adaptation layer will prioritize the principle of high priority and obtain the raw data of Task B from the management queue through the preset queue reading protocol, and extract key task features from the raw data.

[0090] By leveraging a unified adaptation layer to retrieve computational tasks from the management queue and parse their features, standardized adaptation of task retrieval and parsing is achieved, reducing the development and maintenance costs of cross-scenario access, avoiding parsing errors caused by format differences, preventing task omissions and disorderly resource contention, and ensuring processing standardization. Furthermore, providing consistent data support for scheduling can avoid downstream load level judgment biases and ensure the accuracy of scheduling score calculation and task allocation.

[0091] Figure 10 A flowchart of a task scheduling method proposed in an embodiment of this disclosure is further shown. Based on Figure 1 The embodiment shown, Figure 10 This may include the following steps: Step 801: Determine whether the computing task needs to be split based on the load level.

[0092] Based on the load level, it can be determined whether a computing task needs to be split into multiple sub-tasks, thereby achieving load balancing and resource optimization across dies.

[0093] For example, if a computational task is classified as heavy-load, it means that the task involves a large amount of computation and has high resource requirements. In this case, if a single die is assigned to handle the task alone, it may lead to inefficiency due to the excessive workload. Conversely, if the computational task is light-load, it involves a small amount of computation and has low resource requirements, so it does not need to be split and can be handled by a single die. It should be noted that the above examples are for illustrative purposes only and are not intended to limit the specific content.

[0094] Determining whether to split computing tasks based on load levels essentially means adapting the processing method of computing tasks to the computing resource requirements of the task, allowing complex computing tasks to be completed through the collaboration of multiple dies, while simple computing tasks are processed directly by a single die.

[0095] Step 802: If it is determined that the computing task needs to be split, the computing task is divided into at least two sub-tasks.

[0096] In some embodiments, computational tasks that need to be split are divided based on task characteristics (such as data independence and no dependencies). For example, a 2GB video frame feature extraction task (containing 1000 frames of images) that is determined to need to be split is split by the host according to the rule that each frame of image is an independent unit: the computational task is divided into 1000 subtasks, each subtask corresponds to the feature extraction of 1 frame of image (e.g., task size 2MB, estimated execution time 0.3ms), and there are no data dependencies between subtasks, which can be executed in parallel on different dies.

[0097] Step 803: Schedule the computing task to the idle core corresponding to the computing task for execution based on the scheduling score.

[0098] In some embodiments, the scheduling logic prioritizes the kernel with the lowest scheduling score that meets the idle condition (e.g., kernels with a current task queue length ≤ 1 and resource utilization ≤ 20%). For example, if a computational task is determined to be light-load (the computational task does not need to be split), the scheduling scores of three kernels are obtained: DieA (0.2), DieB (0.5), and DieC (0.8). Among them, DieA has a current queue length of 0 and a utilization rate of 15% (meeting the idle condition), while DieB has a queue length of 3 and a utilization rate of 60% (not idle). Therefore, the Host selects DieA based on the scheduling score and directly sends the computational task to DieA's task queue. DieA can execute without waiting, and the time from receiving the task to receiving the result is only 8ms, significantly improving the response efficiency of light-load tasks. It should be noted that the above examples are only illustrative and do not limit the specific content.

[0099] By using the above methods, we can determine whether to split a task based on its load level, thus avoiding the problems of low execution efficiency of a single die for a heavy-load task or wasted resources when splitting a light-load task. By splitting tasks based on their parallelism characteristics, we can ensure that subtasks are independent and controllable. For tasks that do not need to be split, we can select the core based on the scheduling score and idle status, which can ensure the compatibility between tasks and cores and make full use of idle resources to shorten the execution cycle.

[0100] In the embodiments disclosed herein, such as Figure 11 The diagram shows a flowchart of a task scheduling method provided in an embodiment of this disclosure. In response to a received computing task, the task is standardized through a unified adaptation layer. The standardized computing task obtains the performance data of each die through the host and divides the task through the host, resulting in at least two subtasks. A management queue for all subtasks is constructed, and all subtasks are executed locally on each die in the manner of the management queue.

[0101] The embodiments disclosed herein can achieve the following beneficial effects: 1. Reduced latency: The host directly connects to each die, and the communication link is only "host to each die". This saves the transit time of the first die, and the direct communication time from the host to the die is shorter than the total transit time of the first die, so the overall latency will be reduced.

[0102] 2. Enhanced processing power: Task scheduling moves from the first die of the chip to the host, and the CPU on the host has better processing power than the CPU in the first die of the chip.

[0103] 3. Enhanced fault tolerance: When any die in the chip is unavailable, as long as the high-speed bus communication between the host and the first die is normal and the communication between dies is normal, the scheduling of computing tasks will not be affected.

[0104] 4. Flexible scheduling: The host can flexibly select the appropriate scheduling logic between the various dies based on different application scenarios and task characteristics.

[0105] Corresponding to the task scheduling method described above, this invention also proposes a task scheduling apparatus. Since the apparatus embodiments of this invention correspond to the method embodiments described above, details not disclosed in the apparatus embodiments can be referred to in the method embodiments described above, and will not be repeated here.

[0106] Figure 12 This is a schematic diagram of the structure of a task scheduling device provided in an embodiment of the present disclosure, as shown below. Figure 12 As shown, it includes: a first determining unit 51 and a first scheduling unit 52.

[0107] The first determining unit 51 is used to respond to the received computing task by calling the kernel driver to obtain the performance data of at least two cores and to determine the scheduling score corresponding to each core based on the performance data. The first scheduling unit 52 is used to schedule the computing task to the corresponding core for execution based on the scheduling score.

[0108] In summary, according to the task scheduling device provided in this disclosure, the device includes: responding to a received computing task, calling a kernel driver to obtain performance data of at least two cores, and determining a scheduling score corresponding to each core based on the performance data; scheduling the computing task to the corresponding core for execution based on the scheduling score; and achieving precise matching between computing tasks and cores by determining the scheduling score based on the performance data of the core and executing task scheduling, thereby effectively improving the task execution efficiency and resource utilization under a multi-core architecture.

[0109] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the first determining unit 51 includes: The first determining module 511 is used to determine the load level of the computing task in response to the received computing task; The acquisition module 512 is used to collect the performance data corresponding to the at least two cores by calling the kernel driver based on the load level. The calculation module 513 is used to calculate the scheduling score of each core particle based on the performance data using a preset weighted algorithm.

[0110] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the acquisition module 512 includes: The first determining submodule 5121 is used to determine the link latency between the host and the chip by sending and receiving link latency requests between the host and the chip through the kernel driver; The second determining submodule 5122 is used to periodically poll through the kernel driver to obtain the queue depth of the at least two cores and determine the load information based on the queue depth. The acquisition submodule 5123 is used to periodically poll the performance monitoring units of the at least two cores through the kernel driver to obtain the utilization rate of the cores; The performance data includes at least one of the link latency between the host and the chip, the load information of the chip, and the utilization rate of the chip.

[0111] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the first scheduling unit 52 includes: Processing module 521 is used to normalize the scheduling score of each core to obtain a normalized scheduling score. The second determining module 522 is used to determine the scheduling weight corresponding to the normalized scheduling score; The third determining module 523 is used to multiply the total number of subtasks after the calculation task is split by the scheduling weight of each core particle and round down to determine the number of subtasks corresponding to each core particle. The first scheduling module 524 is used to schedule the corresponding number of subtasks to the corresponding cores for execution.

[0112] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the first scheduling unit 52 further includes: The fourth determining module 525 is used to determine the number of unassigned subtasks based on the sum of the number of subtasks corresponding to each core and the total number of subtasks after the calculation task is split by the third determining module 523, after multiplying the total number of subtasks after the calculation task is split by the scheduling weight of each core and rounding down to determine the number of subtasks corresponding to each core and the total number of subtasks. The allocation module 526 is used to allocate the number of unallocated subtasks to the core with the highest scheduling weight.

[0113] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the first determining module 511 includes: The parsing submodule 5111 is used to pass the computing task through a unified adaptation layer and parse the task characteristics of the computing task according to the unified adaptation layer; wherein, the task characteristics include at least one of thread dimension, task size and number of tasks. The partitioning submodule 5112 is used to partition the computing task into different load levels based on the task characteristics.

[0114] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the parsing submodule 5111 is further used for: A management queue for the computing tasks is constructed; wherein the management queue is used to store and manage the computing tasks; The unified adaptation layer retrieves the computing task from the management queue and parses the task characteristics of the computing task.

[0115] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 13 As shown, the device further includes: The judgment unit 53 is used to determine whether the computing task needs to be split according to the load level after the first determination unit 51 determines the scheduling score corresponding to each core according to the performance data. The partitioning unit 54 is used to divide the computing task into at least two subtasks when it is determined that the computing task needs to be split. The first scheduling unit 52 includes: The second scheduling module 527 is used to schedule the computing task to the idle core corresponding to the computing task for execution based on the scheduling score.

[0116] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of the embodiments of this disclosure, and the principle is the same. Therefore, the embodiments of this disclosure are not limited thereto.

[0117] Figure 14 This is a block diagram illustrating an electronic device 900 for implementing a scheduling method for the above-described tasks, according to an exemplary embodiment. For example, the electronic device 900 may be an AI server, a training and promotion integrated machine, etc.

[0118] Reference Figure 14 The electronic device 900 may include one or more of the following components: an AI acceleration computing module 902, a CPU module 904, a power supply module 906, a hard disk module 908, and a fan module 910. Each module works in conjunction with the bus system 912 through a standardized hardware interface, and the specific architecture is as follows: The AI ​​accelerated computing module 902 comprises multiple AI accelerator cards 9021 deployed in parallel. Each AI accelerator card 9021 integrates at least one AI accelerator chip 90211 (such as an RPU chip, GPU chip, CGRA chip, etc.). The AI ​​accelerator cards 9021 communicate with each other via a high-speed card-to-card (C2C) interconnect structure, supporting low-latency, high-bandwidth horizontal scaling. The AI ​​accelerator chip 90211 is dedicated to performing AI computing tasks such as high-density matrix operations, neural network model training and / or inference, providing the main computing power support.

[0119] CPU module 904 includes at least one CPU board 9041, on which a central processing unit (CPU) chip and matching CPU memory 90412 (such as DDR4 / DDR5, RAM) are mounted. The CPU chip 90411 serves as the system control center, responsible for task scheduling, resource allocation, I / O management, and coordinating the parallel operation of the AI ​​acceleration computing module 902, while also handling non-accelerated general-purpose computing tasks.

[0120] Power module 906 is equipped with redundant power supply units to provide stable power distribution and management for AI acceleration computing module 902, CPU module 904 and other modules.

[0121] The 908 hard drive module integrates a high-speed solid-state drive (SSD) and / or a large-capacity hard disk drive (HDD), connected to the system bus via a backplane. The hard drive stores the operating system, AI training datasets, model parameters, and calculation results, providing high-throughput data read / write channels and supporting data preprocessing and persistence.

[0122] The fan module 910 uses a multi-zone independent speed-controlled fan array, which is configured in key heat source areas (such as the AI ​​accelerator card 9021 and the CPU heat dissipation area) to achieve system heat dissipation through forced air cooling and ensure the stable operation of high-efficiency computing components.

[0123] The CPU module 904 is connected to the AI ​​acceleration computing module 902 via the PCIe bus to realize task distribution, result collection and memory coordination.

[0124] CPU module 904 manages data access to hard disk module 908 via SATA / SAS / NVMe interfaces.

[0125] The power module 906 provides tiered power to all functional modules through the power distribution backplane.

[0126] The fan module 910 adjusts the fan speed based on the temperature monitoring signals from the CPU board 9041 and the AI ​​accelerator card 9021.

[0127] Embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in the above embodiments of this disclosure.

[0128] Those skilled in the art will also understand that the various illustrative logical blocks and steps listed in the embodiments of this application can be implemented by electronic hardware, computer software, or a combination of both. Whether such functionality is implemented through hardware or software depends on the specific application and the overall system design requirements. Those skilled in the art can implement the functionality using various methods for each specific application, but such implementation should not be construed as exceeding the scope of protection of the embodiments of this application.

[0129] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0130] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0131] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0132] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0133] It should be understood that various parts of the embodiments of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0134] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0135] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0136] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A task scheduling method, characterized in that, The method is applied to the host's runtime library and includes: In response to the received computing task, the kernel driver is invoked to obtain the performance data of at least two cores, and the scheduling score corresponding to each core is determined based on the performance data. The computational task is scheduled to the corresponding core for execution based on the scheduling score.

2. The method according to claim 1, characterized in that, In response to the received computation task, the kernel driver is invoked to obtain performance data for at least two cores, and the scheduling score for each core is determined based on the performance data, including: In response to a received computing task, determine the load level of the computing task; Based on the load level, the kernel driver is invoked to collect the performance data corresponding to the at least two cores respectively; Based on the performance data, a preset weighted algorithm is used to calculate the scheduling score of each core.

3. The method according to claim 1, characterized in that, The process of calling the kernel driver to obtain performance data for at least two cores includes at least one of the following steps: The link latency between the host and the chip is determined by sending and receiving link latency requests between the host and the chip through the kernel driver; The kernel driver performs periodic polling to obtain the queue depth of at least two cores, and determines the load information based on the queue depth. The kernel driver periodically polls the performance monitoring units of each of the at least two cores to obtain the core utilization rate. The performance data includes at least one of the link latency between the host and the chip, the load information of the chip, and the utilization rate of the chip.

4. The method according to claim 1, characterized in that, The step of scheduling the computation task to the corresponding core based on the scheduling score includes: The scheduling score of each core is normalized to obtain the normalized scheduling score; Determine the scheduling weight corresponding to the normalized scheduling score; The total number of subtasks after the computation task is split is multiplied by the scheduling weight of each core particle and rounded down to determine the number of subtasks corresponding to each core particle. The corresponding number of subtasks are scheduled to be executed by the corresponding core particles.

5. The method according to claim 4, characterized in that, After determining the number of subtasks corresponding to each core by multiplying the total number of subtasks after splitting the computation task with the scheduling weight of each core and rounding down, the process includes: The number of unassigned subtasks is determined based on the sum of the number of subtasks corresponding to each core and the total number of subtasks. The number of unassigned subtasks is allocated to the core with the highest scheduling weight.

6. The method according to claim 1, characterized in that, The step of determining the load level of the received computing task includes: The computation task is passed through a unified adaptation layer, and the task characteristics of the computation task are obtained by parsing the unified adaptation layer; wherein, the task characteristics include at least one of thread dimension, task size and number of tasks; Based on the task characteristics, the computing tasks are divided into different load levels.

7. The method according to claim 6, characterized in that, The step of passing the computation task through a unified adaptation layer and resolving the task characteristics of the computation task based on the unified adaptation layer includes: A management queue for the computing tasks is constructed; wherein the management queue is used to store and manage the computing tasks; The unified adaptation layer retrieves the computing task from the management queue and parses the task characteristics of the computing task.

8. The method according to claim 1, characterized in that, After determining the scheduling score corresponding to each core based on the performance data, the method further includes: Determine whether the computing task needs to be split based on the load level; If it is determined that the computing task needs to be split, the computing task shall be divided into at least two sub-tasks; The step of scheduling the computation task to the corresponding core based on the scheduling score includes: The computation task is scheduled to be executed in an idle core corresponding to the computation task based on the scheduling score.

9. A task scheduling device, characterized in that, include: The first determining unit is configured to determine the load level of the computing task in response to the received computing task. The second determining unit is used to obtain performance data of at least two cores based on the load level, and determine the scheduling score corresponding to each core based on the performance data. The first scheduling unit is used to schedule the computing task to the corresponding core for execution based on the scheduling score.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

Images