Thread scheduling method and apparatus, electronic device, storage medium, and program product

Abstract

This disclosure relates to a thread scheduling method, apparatus, electronic device, storage medium, and program product. The method includes: in response to a target thread being awakened, identifying the type of the target thread, wherein the target thread is a thread submitted by the central processing unit (CPU) waiting for a graphics processing unit (GPU) to complete an event; threads waiting for GPU completion events are pre-classified according to their low-latency requirements, and different scheduling policies are pre-assigned to different types of threads waiting for GPU completion events; allocating a CPU to the target thread according to the scheduling policy corresponding to the target thread's type; and executing the target thread using the allocated CPU. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, and that latency-insensitive threads waiting for GPU completion events are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to thread scheduling methods, apparatus, electronic devices, storage media, and program products. Background Technology

[0002] With the widespread application of Graphics Processing Units (GPUs) in fields such as artificial intelligence inference, graphics rendering, and scientific computing, heterogeneous collaborative computing between Central Processing Units (CPUs) and GPUs is becoming increasingly important. In these heterogeneous computing scenarios, CPU threads often need to submit tasks to the GPU for execution, and then wait for the GPU to complete the task before processing the GPU's execution results.

[0003] In the Linux kernel, GPU drivers typically use synchronization mechanisms such as Direct Memory Access Fence (DMA Fence) to notify CPU threads that the GPU task has been completed. Once the GPU finishes computation, it can generate an interrupt, which can then wake up waiting CPU threads. These awakened CPU threads can then be scheduled to run on the CPU by the kernel scheduler at an appropriate time. In related technologies, all threads are scheduled in the same way, which can lead to scheduling imbalances and poor thread scheduling efficiency. Summary of the Invention

[0004] This disclosure provides thread scheduling methods, apparatus, electronic devices, storage media, and program products to at least solve the problems of unbalanced thread scheduling and poor scheduling effect in the aforementioned related technologies.

[0005] According to a first aspect of the present disclosure, a thread scheduling method is provided, comprising: in response to a target thread being awakened, identifying the type of the target thread, wherein the target thread is a thread submitted by a central processing unit (CPU) waiting for a graphics processing unit (GPU) to complete an event, the threads waiting for the GPU to complete the event are pre-classified according to the degree of low latency requirement, and different scheduling policies are pre-assigned to different types of threads waiting for the GPU to complete the event, wherein the scheduling policy includes a scheduling priority, and the scheduling priority is positively correlated with the degree of low latency requirement of the thread; allocating a CPU to the target thread according to the scheduling policy corresponding to the type of the target thread; and executing the target thread through the allocated CPU.

[0006] Optionally, before identifying the type of the target thread in response to the target thread being awakened, the method further includes: establishing a GPU wait context in the kernel of the operating system, wherein the GPU wait context is used to describe the attributes of the target thread, and the GPU wait context contains the type of the target thread; identifying the type of the target thread in response to the target thread being awakened includes: reading the type of the target thread from the established GPU wait context in response to the target thread being awakened.

[0007] Optionally, the GPU waiting context further includes the scheduling deadline of the target thread; the thread scheduling method further includes: reading the scheduling deadline from the established GPU waiting context; allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: increasing the scheduling priority of the awakened target thread if the current time distance from the read scheduling deadline is less than a preset target duration; and allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread based on the increased scheduling priority.

[0008] Optionally, allocating CPU to the target thread according to the scheduling strategy corresponding to the type of the target thread includes: allocating CPU to the target thread using a low-latency scheduling strategy when the type of the target thread is a low-latency interactive type; allocating CPU to the target thread using a batch scheduling strategy when the type of the target thread is a batch processing type; and allocating CPU to the target thread using a normal scheduling strategy when the type of the target thread is a normal type; wherein the low-latency requirement decreases sequentially from the low-latency interactive type, the batch processing type, and the normal type, and the scheduling timeliness decreases sequentially from the low-latency scheduling strategy, the batch scheduling strategy, and the normal scheduling strategy.

[0009] Optionally, when the target thread is of the low-latency interaction type, allocating CPU to the target thread using a low-latency scheduling strategy includes: generating a synchronization wake-up flag and / or a latency-sensitive prompt when the target thread is of the low-latency interaction type; sending the synchronization wake-up flag and / or the latency-sensitive prompt to the scheduler through the awakened target thread; allocating CPU to the awakened target thread based on the synchronization wake-up flag within a preset first duration through the scheduler, and / or allocating CPU to the awakened target thread based on the latency-sensitive prompt for a usage time of a preset second duration.

[0010] Optionally, when the target thread is of batch processing type, allocating CPU to the target thread using a batch scheduling strategy includes: when the target thread is of batch processing type, determining whether the current batch scheduling cycle has ended; if it is determined that the current batch scheduling cycle has not ended, adding the awakened target thread to the thread aggregation queue; if the current batch scheduling cycle has ended, submitting at least one thread in the thread aggregation queue to the scheduler; and allocating CPU to the at least one thread through the scheduler.

[0011] Optionally, when the target thread is of a normal type, allocating CPU to the target thread using a normal scheduling strategy includes: when the target thread is of the normal type, determining whether the current fair scheduling period has ended; if it is determined that the current fair scheduling period has not ended, adding the awakened target thread to the fair scheduling queue; if the current fair scheduling period has ended, submitting at least one thread in the fair scheduling queue to the scheduler; and allocating CPU to the at least one thread with the same time slice through the scheduler.

[0012] Optionally, allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: allocating a local CPU to the awakened target thread according to the scheduling policy corresponding to the type of the target thread, wherein the local CPU is the CPU of the target thread that submitted the event waiting for GPU completion.

[0013] Optionally, allocating a CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: allocating a clustered CPU to the awakened target thread according to the scheduling policy corresponding to the type of the target thread, wherein the clustered CPU is a CPU that is in the same non-consistent memory access node as the local CPU, and the local CPU is the CPU of the target thread that submitted the waiting for the GPU completion event.

[0014] According to a second aspect of the present disclosure, a thread scheduling apparatus is provided, comprising: a type identification module configured to identify the type of a target thread in response to the target thread being awakened, wherein the target thread is a thread submitted by a central processing unit (CPU) waiting for a graphics processing unit (GPU) to complete an event, the threads waiting for the GPU to complete the event are pre-classified according to their low latency requirements, and different scheduling strategies are pre-assigned to different types of threads waiting for the GPU to complete the event, wherein the scheduling strategy includes a scheduling priority, and the scheduling priority is positively correlated with the thread's low latency requirements; an allocation module configured to allocate a CPU to the target thread according to the scheduling strategy corresponding to the type of the target thread; and an execution module configured to execute the target thread using the allocated CPU.

[0015] Optionally, the thread scheduling device further includes: an establishment module configured to establish a GPU wait context in the kernel of the operating system, wherein the GPU wait context is used to describe the attributes of the target thread, and the GPU wait context includes the type of the target thread; the type identification module is configured to: read the type of the target thread from the established GPU wait context in response to the target thread being awakened.

[0016] Optionally, the GPU waiting context further includes the scheduling deadline of the target thread; the thread scheduling device further includes: a reading module configured to read the scheduling deadline from the established GPU waiting context; the allocation module is configured to: increase the scheduling priority of the awakened target thread if the current time distance from the read scheduling deadline is less than a preset target duration; and allocate CPU to the target thread based on the increased scheduling priority and the scheduling strategy corresponding to the type of the target thread.

[0017] Optionally, the allocation module is configured to: allocate CPU to the target thread using a low-latency scheduling strategy when the target thread type is a low-latency interaction type; allocate CPU to the target thread using a batch scheduling strategy when the target thread type is a batch processing type; and allocate CPU to the target thread using a normal scheduling strategy when the target thread type is a normal type; wherein the low-latency requirement decreases sequentially for the low-latency interaction type, the batch processing type, and the normal type, and the scheduling timeliness decreases sequentially for the low-latency scheduling strategy, the batch scheduling strategy, and the normal scheduling strategy.

[0018] Optionally, the allocation module is configured to: generate a synchronization wake-up flag and / or a latency-sensitive prompt when the target thread is of the low-latency interaction type; send the synchronization wake-up flag and / or the latency-sensitive prompt to the scheduler through the awakened target thread; allocate CPU to the awakened target thread within a preset first duration based on the synchronization wake-up flag, and / or allocate CPU to the awakened target thread for a usage time of a preset second duration based on the latency-sensitive prompt.

[0019] Optionally, the allocation module is configured to: if the target thread type is the batch processing type, determine whether the current batch scheduling cycle has ended; if it is determined that the current batch scheduling cycle has not ended, add the awakened target thread to the thread aggregation queue; if the current batch scheduling cycle has ended, submit at least one thread in the thread aggregation queue to the scheduler; and allocate CPU to the at least one thread through the scheduler.

[0020] Optionally, the allocation module is configured to: determine whether the current fair scheduling period has ended if the target thread is of the normal type; add the awakened target thread to the fair scheduling queue if the current fair scheduling period has not ended; submit at least one thread in the fair scheduling queue to the scheduler if the current fair scheduling period has ended; and allocate the CPU with the same time slice to the at least one thread through the scheduler.

[0021] Optionally, the allocation module is configured to: allocate a local CPU to the awakened target thread according to the scheduling policy corresponding to the type of the target thread, wherein the local CPU is the CPU of the target thread that submitted the event waiting for the GPU to complete.

[0022] Optionally, the allocation module is configured to: allocate a clustered CPU to the awakened target thread according to the scheduling policy corresponding to the type of the target thread, wherein the clustered CPU is a CPU that is in the same non-consistent memory access node as the local CPU, and the local CPU is the CPU of the target thread that submitted the waiting for the GPU completion event.

[0023] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a thread scheduling method according to the present disclosure.

[0024] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform a thread scheduling method according to the present disclosure.

[0025] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a thread scheduling method according to the present disclosure.

[0026] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: This disclosure allows for the differentiation of thread types waiting for GPU completion events. Consequently, awakened threads waiting for GPU completion events can be scheduled according to their respective scheduling strategies, enabling differentiated scheduling for different types of threads. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, while latency-insensitive threads are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

[0027] According to exemplary embodiments of this disclosure, by setting a synchronization wake-up flag and / or a latency-sensitive cue for threads waiting for GPU completion events of low-latency interaction type, threads waiting for GPU completion events of low-latency interaction type can be selected by the scheduler more quickly, thereby effectively reducing tail latency.

[0028] According to an exemplary embodiment of this disclosure, for batch-type threads waiting for GPU completion events, group scheduling can be performed by adopting a batch scheduling strategy to avoid wake-up storms while ensuring low latency requirements. This avoids CPU preemption storms and sudden increases in the runnable queue caused by a large number of threads being woken up at the same time. The runnable queue can refer to a queue of threads that are ready to run but have not yet been allocated CPU.

[0029] According to an exemplary embodiment of this disclosure, when the current time is close to the scheduling deadline, it indicates that the scheduling requirement for the corresponding threads waiting for GPU completion events is imminent. Therefore, at this time, the scheduling priority of the corresponding threads waiting for GPU completion events can be increased, thereby ensuring that the corresponding threads waiting for GPU completion events can be scheduled first, thus guaranteeing the timeliness of scheduling.

[0030] According to an exemplary embodiment of this disclosure, by allocating a local CPU to the awakened target thread, the number of times the target thread migrates between CPUs can be reduced, thereby reducing cross-CPU migration overhead.

[0031] According to an exemplary embodiment of this disclosure, by allocating a CPU in the same cluster to the awakened target thread, the target thread can be avoided from migrating between different nodes, thereby effectively reducing the overhead of cross-node migration.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0034] Figure 1 This is a flowchart illustrating a thread scheduling method according to an exemplary embodiment of the present disclosure; Figure 2 This is an interactive flowchart illustrating a thread scheduling method according to an exemplary embodiment of the present disclosure; Figure 3 This is a flowchart illustrating a specific implementation of a thread scheduling method according to an exemplary embodiment of the present disclosure; Figure 4 This is a block diagram illustrating a thread scheduling apparatus according to exemplary embodiments of the present disclosure; Figure 5 This is a block diagram illustrating an electronic device according to exemplary embodiments of the present disclosure. Detailed Implementation

[0035] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0036] 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 examples 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.

[0037] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which indicates the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0038] It's important to note that threads waiting for GPU task execution can be of various types. In related technologies, there's no difference in wake-up and scheduling for these different thread types; that is, all threads use the same wake-up and scheduling strategies. However, some thread types are more sensitive to latency and need to be scheduled as quickly as possible, while others are less sensitive and don't require prompt scheduling. If the same wake-up and scheduling strategy is used for all thread types, it's possible that latency-sensitive threads may not be scheduled for a long time, or that latency-insensitive threads may be given unnecessary priority. Therefore, the thread scheduling methods in related technologies suffer from an imbalance, resulting in poor thread scheduling performance.

[0039] To address the aforementioned problems in related technologies, the thread scheduling method, apparatus, electronic device, storage medium, and program product provided in this disclosure can distinguish the types of threads waiting for GPU completion events. Furthermore, it can schedule awakened threads waiting for GPU completion events according to the scheduling strategies corresponding to each type of thread, enabling differentiated scheduling for different types of threads waiting for GPU completion events. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, while latency-insensitive threads are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

[0040] Figure 1 This is a flowchart illustrating a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0041] Reference Figure 1In step 101, in response to the target thread being awakened, the type of the target thread can be identified. The target thread can be a thread submitted by the central processing unit (CPU) waiting for the graphics processing unit (GPU) to complete an event. Furthermore, threads waiting for GPU completion events can be pre-classified based on their low-latency requirements. Different scheduling strategies can be pre-assigned to different types of threads waiting for GPU completion events. These scheduling strategies can include scheduling priorities, and the scheduling priority can be positively correlated with the thread's low-latency requirement.

[0042] For example, based on application scenarios and performance requirements, target threads can be categorized into, but are not limited to, the following categories: 1. Low-latency interactive threads: These threads require extremely low wake-up latency. Examples include, but are not limited to: post-processing threads for Artificial Intelligence (AI) inference requests, critical path threads for graphics rendering, etc.

[0043] 2. Batch processing type: This type of thread can tolerate a certain delay. For example, it can be, but is not limited to: batch inference tasks (workers), offline rendering tasks, etc.

[0044] 3. Normal waiting type: This type of thread has no special performance requirements.

[0045] It should be noted that threads can be further categorized into more detailed types based on their need for low-latency interaction. This disclosure does not impose specific limitations in this regard, and the aforementioned implementation is merely an illustrative example. Furthermore, in this disclosure, it can be first determined whether the target thread is a thread waiting for a GPU completion event or another type of I / O thread. If it is determined that the target thread is a thread waiting for a GPU completion event, the specific type of the thread waiting for the GPU completion event can be further identified, i.e., whether the thread waiting for the GPU completion event is a low-latency interaction type, a batch processing type, or a normal waiting type.

[0046] According to exemplary embodiments of this disclosure, a GPU wait context can also be established in the operating system kernel. This GPU wait context can be used to describe the attributes of the target thread, specifically its thread scheduling-related characteristics. The GPU wait context can contain the type of the target thread. Then, in response to the target thread being awakened, the type of the target thread can be read from the established GPU wait context.

[0047] It should be noted that while a thread is waiting for the GPU to process a task, a GPU wait context can be established, and this GPU wait context can be maintained in a driver-private structure, a synchronization object association structure, or a kernel module. For example, this GPU wait context may contain, but is not limited to, the following information: 1. The identifier (task_struct pointer) of the thread waiting for the GPU to complete the event.

[0048] 2. The GPU synchronization object (e.g., dma_fence) associated with the thread waiting for the GPU completion event.

[0049] 3. Policy flags: These identify the type of thread waiting for GPU completion events, such as low-latency interactive, batch, or normal waiting. Additionally, policy flags can be set in the GPU waiting context via user-space interface or driver internal logic before a thread entering the waiting state.

[0050] 4. Service Quality Level (qos_class).

[0051] 5. Optional scheduling deadline (deadline_ns).

[0052] 6. The CPU number that is preferred to be woken up (preferred_cpu).

[0053] 7. Local wake-up preference flag (local_wake_preferred).

[0054] In step 102, a CPU can be allocated to the target thread according to the scheduling policy corresponding to the type of the target thread. For example, attribute information from the GPU waiting context, such as policy flags (the type of thread waiting for the GPU to complete an event), scheduling deadlines, and quality of service levels, can be passed to the scheduler, which can then use this attribute information to schedule the target thread.

[0055] It should be noted that in this disclosure, the scheduling of threads waiting for GPU completion events can be implemented based on `dma_fence`. Specifically, while a thread waiting for a GPU completion event is waiting for the GPU to execute a task, the aforementioned GPU waiting context can be associated with the target `dma_fence`. Then, a dedicated fence callback function can be registered. Next, when the fence is signaled, the callback function can perform differentiated wake-up and scheduling based on the GPU waiting context. This process may include, but is not limited to, determining the type of thread waiting for a GPU completion event, selecting a suitable CPU, setting the wake-up flag (WF_SYNC), and carrying scheduling hints, etc.

[0056] In this disclosure, the scheduling of threads waiting for GPU completion events can also be achieved by setting up a private wait queue. Specifically, a dedicated private wait queue can be maintained by the GPU driver. When a thread waiting for a GPU completion event enters a waiting state, it can be added to the private wait queue, and its attributes can be recorded. Thus, after the GPU completes its task, it can be scheduled differently based on the attributes of the threads waiting for GPU completion events. For example, threads waiting for GPU completion events of low-latency interaction type can be woken up immediately and can carry a latency-sensitive tag to notify the scheduler to allocate a sufficiently long time slice for them; threads waiting for GPU completion events of batch processing type can be grouped for scheduling, and so on.

[0057] According to exemplary embodiments of this disclosure, when the target thread is of a low-latency interactive type, a low-latency scheduling strategy can be used to allocate CPU to the target thread; when the target thread is of a batch processing type, a batch scheduling strategy can be used to allocate CPU to the target thread; and when the target thread is of a normal type, a normal scheduling strategy can be used to allocate CPU to the target thread. The low-latency requirement for low-latency interactive type, batch processing type, and normal type can decrease sequentially; and the scheduling timeliness of low-latency scheduling strategy, batch scheduling strategy, and normal scheduling strategy can decrease sequentially.

[0058] In this way, by distinguishing the types of threads waiting for the GPU to complete events, it is possible to flexibly configure wake-up and scheduling strategies according to different application scenarios, which can meet the low latency requirements while taking into account the overall system performance.

[0059] According to an exemplary embodiment of this disclosure, when the target thread is of a low-latency interaction type, a synchronization wake-up flag (WF_SYNC) and / or a latency-sensitive hint can be generated. Then, the wake-up flag and / or latency-sensitive hint can be sent to the scheduler by the awakened target thread. Next, the scheduler can allocate CPU to the awakened target thread based on the synchronization wake-up flag within a preset first duration (immediately), and can allocate CPU to the awakened target thread based on the latency-sensitive hint for a usage time of a preset second duration. That is, the latency-sensitive hint is mainly used to constrain the time slice allocated to the thread by the CPU to reach a certain length.

[0060] In this way, by setting a synchronization wake-up flag and / or latency-sensitive hints for threads waiting for GPU completion events of low-latency interaction types, these threads can be selected by the scheduler more quickly, thereby effectively reducing tail latency. It should be noted that an anti-migration flag can also be generated for these threads to ensure they are scheduled to the original CPU on which they submitted the event, thus reducing cross-CPU migration.

[0061] According to an exemplary embodiment of this disclosure, when the target thread is of batch processing type, it can be determined whether the current batch scheduling cycle has ended. If it is determined that the current batch scheduling cycle has not ended, the awakened target thread can be added to the thread aggregation queue. If the current batch scheduling cycle has ended, at least one thread in the thread aggregation queue can be submitted to the scheduler. Then, the scheduler can allocate CPU to at least one thread.

[0062] In this way, for batch-type threads waiting for GPU completion events, group scheduling can be performed by adopting a batch scheduling strategy. This can avoid wake-up storms while ensuring low latency requirements. Specifically, it can avoid CPU preemption storms and sudden increases in the runnable queue caused by a large number of threads being woken up at the same time. The runnable queue can refer to a queue of threads that are ready to run but have not yet been allocated CPU.

[0063] According to an exemplary embodiment of this disclosure, when the target thread is of a normal type, it can be determined whether the current fair scheduling period has ended. If it is determined that the current fair scheduling period has not ended, the awakened target thread can be added to the fair scheduling queue. If the current fair scheduling period has ended, at least one thread in the fair scheduling queue can be submitted to the scheduler. Then, the scheduler can allocate CPU time slices equally to at least one thread.

[0064] According to an exemplary embodiment of this disclosure, the GPU wait context may further include the scheduling deadline of the target thread. The scheduling deadline can be read from the established GPU wait context. If the current time is less than the read scheduling deadline, the scheduling priority of the awakened target thread can be increased. Then, based on the increased scheduling priority, CPU can be allocated to the target thread according to the scheduling policy corresponding to the type of the target thread.

[0065] Thus, as the scheduling deadline approaches, the scheduling needs of threads waiting for GPU completion events become urgent. Therefore, the scheduling priority of these threads can be increased at this point, ensuring they are scheduled first and guaranteeing timely scheduling.

[0066] According to an exemplary embodiment of this disclosure, a local CPU can be allocated to a woken-up target thread according to a scheduling policy corresponding to the type of the target thread, wherein the local CPU can be the CPU of the target thread that has submitted an event waiting for the GPU to complete.

[0067] It should be noted that the thread scheduling mechanism in related technologies may schedule threads to a different CPU than when the task was submitted, which can lead to significant migration overhead. To address this, this disclosure reduces the number of CPU thread migrations between CPUs by allocating a local CPU to the awakened target thread, thereby reducing cross-CPU migration overhead.

[0068] According to an exemplary embodiment of this disclosure, a clustered CPU can be allocated to the awakened target thread according to the scheduling policy corresponding to the type of the target thread. The clustered CPU can be a CPU that is in the same Non-Uniform Memory Access (NUMA) node as the local CPU, and the local CPU can be the CPU of the target thread that submitted the event waiting for the GPU to complete.

[0069] In this way, by allocating CPUs in the same cluster to the awakened target thread, the migration of threads waiting for the GPU to complete events between different nodes can be avoided, thereby effectively reducing the overhead of cross-node migration.

[0070] In step 103, the target thread can be executed using the allocated CPU.

[0071] This disclosure allows for differentiated scheduling without directly modifying the thread scheduling class (e.g., forcibly switching to the SCHED_FIFO: First In First Out scheduling policy). Instead, it differentiates scheduling by the type of thread waiting for GPU completion events. This does not violate the semantics of the Completely Fair Scheduler (CFS) / Real-Time Scheduler (RT), thus avoiding priority inversion and starvation issues. In other words, this disclosure significantly reduces end-to-end latency, particularly tail latency, in heterogeneous GPU computing scenarios by identifying the type of thread waiting for GPU completion events and providing a differentiated scheduling acceleration mechanism, without violating existing kernel scheduling semantics or introducing security risks. Furthermore, by reducing the scheduling latency of threads waiting for GPU completion events, the idle time of the GPU waiting for CPU processing results is reduced, improving the processing efficiency of the GPU-CPU pipeline.

[0072] Figure 2 This is an interactive flowchart illustrating a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0073] Reference Figure 2 The interaction process of thread scheduling mainly involves threads waiting for GPU completion events, GPU drivers, GPU hardware, GPU waiting contexts, dedicated wake-up modules, and schedulers. Threads waiting for GPU completion events can submit computational tasks to GPU hardware through the GPU driver; the GPU waiting context is mainly used to describe the attributes of the thread; the dedicated wake-up module is mainly used to select the appropriate wake-up and scheduling strategy based on the thread type; and the scheduler is mainly used to allocate CPU time to the woken-up threads to achieve scheduling.

[0074] In step 201, threads waiting for GPU completion events can submit computational tasks to the GPU hardware through the GPU driver.

[0075] In step 202, a GPU wait context can be established in the operating system kernel, whereby the GPU wait context can be used to describe the attributes of threads waiting for GPU completion events.

[0076] For example, the GPU wait context may include, but is not limited to, the following information: the identifier of the thread waiting for the GPU completion event, the GPU synchronization object associated with the thread waiting for the GPU completion event (e.g., dma_fence), the policy flag (used to identify the type of thread waiting for the GPU completion event), the quality of service level, the optional scheduling deadline, the CPU number to be woken up first, and the local wake-up preference flag.

[0077] In step 203, the thread waiting for the GPU to complete the event can be controlled to enter a waiting (sleep) state.

[0078] In step 204, the computation task submitted by the thread waiting for the GPU completion event is executed by the GPU hardware.

[0079] In step 205, after the GPU hardware has completed the computation task, a completion interrupt signal can be sent to the GPU driver.

[0080] In step 206, the GPU driver can query the type of thread waiting for the GPU completion event from the aforementioned GPU wait context.

[0081] In step 207, if the type of thread waiting for the GPU completion event is a low-latency interaction type, the dedicated wake-up module can generate a synchronous wake-up flag and / or a latency-sensitive prompt.

[0082] In step 208, the dedicated wake-up module can send the generated synchronous wake-up flag and / or delay-sensitive prompt to the thread that is currently sleeping and waiting for the GPU completion event to wake up the thread waiting for the GPU completion event.

[0083] In step 209, the awakened thread waiting for the GPU completion event can send a synchronization wake-up flag and / or a delay-sensitive hint to the scheduler.

[0084] In step 2010, the scheduler can immediately allocate CPU to the awakened thread waiting for GPU completion event based on the synchronization wake-up flag, and can specify that the CPU allocated to the awakened thread waiting for GPU completion event needs to be used for a certain duration based on the latency sensitivity hint.

[0085] In step 2011, if the type of thread waiting for the GPU completion event is batch processing, the dedicated wake-up module can determine whether the current batch scheduling cycle has ended. If it is determined that the current batch scheduling cycle has not ended, the thread waiting for the GPU completion event can be added to the thread aggregation queue.

[0086] In step 2012, when the current batch scheduling cycle ends, the dedicated wake-up module can wake up threads that are in a sleep state and waiting for the GPU to complete the event.

[0087] In step 2013, the scheduler may allocate CPU to at least one thread contained in the thread aggregation queue at the end of the current batch scheduling cycle.

[0088] In step 2014, if the thread waiting for the GPU completion event is of the normal type, the dedicated wake-up module can determine whether the current fair scheduling cycle has ended. If it is determined that the current fair scheduling cycle has not ended, the thread waiting for the GPU completion event can be added to the fair scheduling queue.

[0089] In step 2015, if the current fair scheduling cycle ends, the dedicated wake-up module can wake up threads that are in a sleep state and waiting for the GPU to complete the event.

[0090] In step 2016, the scheduler may allocate CPU time slices equally to at least one thread contained in the fair scheduling queue at the end of the current fair scheduling period.

[0091] In step 2017, the awakened thread waiting for the GPU completion event uses the CPU allocated to it by the scheduler to process the execution result of the GPU hardware execution computing task.

[0092] This disclosure allows for the differentiation of thread types waiting for GPU completion events. Consequently, awakened threads waiting for GPU completion events can be scheduled according to their respective scheduling strategies, enabling differentiated scheduling for different types of threads. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, while latency-insensitive threads are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

[0093] Figure 3 This is a flowchart illustrating a specific implementation of a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0094] Reference Figure 3 In step 301, the thread waiting for the GPU completion event submits the computing task to the GPU hardware through the GPU driver.

[0095] In step 302, the GPU hardware executes a computational task and triggers a completion interrupt signal upon completion of the computational task.

[0096] In step 303, the type of the thread waiting for the GPU completion event is queried from the GPU wait context of the thread waiting for the GPU completion event.

[0097] In step 304, if the type of the thread waiting for the GPU to complete the event is a low-latency interaction type, a synchronous wake-up flag, a latency-sensitive warning, and an anti-migration flag are generated.

[0098] In step 305, the thread that is currently sleeping and waiting for the GPU to complete the event is awakened.

[0099] In step 306, if the type of the thread waiting for the GPU completion event is batch processing, it is determined whether the current batch scheduling cycle has ended.

[0100] In step 307, if the current batch scheduling cycle has not yet ended, the threads waiting for the GPU completion event are added to the thread aggregation queue.

[0101] In step 308, wait for the current batch scheduling cycle to end.

[0102] In step 309, if the current batch scheduling cycle has ended, a new batch scheduling cycle is started.

[0103] In step 3010, if the batch scheduling cycle ends, threads that are in a sleep state and waiting for the GPU to complete the event can be woken up.

[0104] In step 3011, if the type of the thread waiting for the GPU completion event is a normal type, a standard wake-up strategy can be used to wake up the thread waiting for the GPU completion event. The standard wake-up strategy can be a wake-up strategy in related technologies.

[0105] In step 3012, the awakened thread waiting for the GPU completion event can be added to the runnable queue.

[0106] In step 3013, the scheduler can allocate CPU to the awakened threads waiting for GPU completion events based on the GPU waiting context corresponding to each type of thread waiting for GPU completion events, so as to schedule the awakened threads waiting for GPU completion events.

[0107] This disclosure allows for the differentiation of thread types waiting for GPU completion events. Consequently, awakened threads waiting for GPU completion events can be scheduled according to their respective scheduling strategies, enabling differentiated scheduling for different types of threads. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, while latency-insensitive threads are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

[0108] Figure 4 This is a block diagram illustrating a thread scheduling apparatus 400 according to an exemplary embodiment of the present disclosure.

[0109] Reference Figure 4 The thread scheduling device 400 may include a type identification module 401, an allocation module 402, and an execution module 403.

[0110] In response to the target thread being awakened, the type identification module 401 can identify the type of the target thread, wherein the target thread can be a thread submitted by the central processing unit (CPU) waiting for the graphics processing unit (GPU) to complete the event. Furthermore, threads waiting for GPU completion events can be pre-classified according to their low-latency requirements, and different scheduling strategies can be pre-assigned to different types of threads waiting for GPU completion events. This scheduling strategy can include scheduling priorities, and the scheduling priority can be positively correlated with the thread's low-latency requirements.

[0111] According to an exemplary embodiment of this disclosure, the thread scheduling device 400 may further include an establishment module.

[0112] The establishment module can create a GPU wait context in the operating system kernel. This GPU wait context can be used to describe the attributes of the target thread, that is, to describe the thread scheduling-related characteristics of the target thread. The GPU wait context can contain the type of the target thread. Then, in response to the target thread being awakened, the type recognition module 401 can read the type of the target thread from the established GPU wait context.

[0113] The allocation module 402 can allocate a CPU to the target thread according to the scheduling policy corresponding to the type of the target thread. For example, it can pass the attribute information in the GPU waiting context, such as policy flags (the type of thread waiting for the GPU to complete the event), scheduling deadline, quality of service level, etc., to the scheduler, and then the scheduler can use this attribute information to schedule the target thread.

[0114] According to an exemplary embodiment of this disclosure, when the target thread is of the low-latency interaction type, the allocation module 402 can use a low-latency scheduling strategy to allocate CPU to the target thread; when the target thread is of the batch processing type, the allocation module 402 can use a batch scheduling strategy to allocate CPU to the target thread; when the target thread is of the normal type, the allocation module 402 can use a normal scheduling strategy to allocate CPU to the target thread. The low-latency requirement for low-latency interaction type, batch processing type, and normal type can decrease sequentially; the scheduling timeliness of low-latency scheduling strategy, batch scheduling strategy, and normal scheduling strategy can decrease sequentially.

[0115] According to an exemplary embodiment of this disclosure, when the target thread is of a low-latency interaction type, the allocation module 402 can generate a synchronization wake-up flag (WF_SYNC) and / or a latency-sensitive hint. Then, the allocation module 402 can send the synchronization wake-up flag and / or latency-sensitive hint to the scheduler via the awakened target thread. Next, the allocation module 402 can allocate CPU to the awakened target thread within a preset first duration (immediately) based on the synchronization wake-up flag, and can allocate CPU for a usage duration of a preset second duration based on the latency-sensitive hint. That is, the latency-sensitive hint is mainly used to constrain the time slice allocated to the thread by the CPU to reach a certain length.

[0116] According to an exemplary embodiment of this disclosure, when the target thread is of batch processing type, the allocation module 402 can determine whether the current batch scheduling cycle has ended. If it is determined that the current batch scheduling cycle has not ended, the allocation module 402 can add the awakened target thread to the thread aggregation queue. If the current batch scheduling cycle has ended, the allocation module 402 can submit at least one thread in the thread aggregation queue to the scheduler. Then, the allocation module 402 can allocate CPU to at least one thread through the scheduler.

[0117] According to an exemplary embodiment of this disclosure, when the target thread is of a normal type, the allocation module 402 can determine whether the current fair scheduling period has ended. If it is determined that the current fair scheduling period has not ended, the allocation module 402 can add the awakened target thread to the fair scheduling queue. If the current fair scheduling period has ended, the allocation module 402 can submit at least one thread in the fair scheduling queue to the scheduler. Then, the allocation module 402 can allocate CPU time slices to at least one thread equally using the scheduler.

[0118] According to an exemplary embodiment of this disclosure, the thread scheduling device 400 described above may further include a reading module.

[0119] The GPU wait context can also contain the scheduling deadline of the target thread. The reading module can read the scheduling deadline from the established GPU wait context. If the current time is less than the read scheduling deadline and the time remaining is less than the preset target duration, the allocation module 402 can increase the scheduling priority of the awakened target thread. Then, based on the increased scheduling priority, the allocation module 402 can allocate CPU to the target thread according to the scheduling policy corresponding to the type of the target thread.

[0120] According to an exemplary embodiment of this disclosure, the allocation module 402 can allocate a local CPU to the awakened target thread according to the scheduling policy corresponding to the type of the target thread, wherein the local CPU can be the CPU of the target thread that has submitted an event waiting for the GPU to complete.

[0121] According to an exemplary embodiment of this disclosure, the allocation module 402 can allocate a clustered CPU to the awakened target thread according to the scheduling policy corresponding to the type of the target thread. The clustered CPU can be a CPU under the same NUMA node as the local CPU, and the local CPU can be the CPU of the target thread that has submitted an event waiting for the GPU to complete.

[0122] Execution module 403 can execute the target thread using the allocated CPU.

[0123] This disclosure allows for the differentiation of thread types waiting for GPU completion events. Consequently, awakened threads waiting for GPU completion events can be scheduled according to their respective scheduling strategies, enabling differentiated scheduling for different types of threads. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, while latency-insensitive threads are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

[0124] Figure 5 This is a block diagram illustrating an electronic device 500 according to an exemplary embodiment of the present disclosure.

[0125] Reference Figure 5 The electronic device 500 includes at least one memory 501 and at least one processor 502. The at least one memory 501 stores instructions that, when executed by the at least one processor 502, execute a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0126] As an example, electronic device 500 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned instructions. Here, electronic device 500 is not necessarily a single electronic device, but may be a collection of any devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 500 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0127] In electronic device 500, processor 502 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0128] The processor 502 can execute instructions or code stored in the memory 501, which can also store data. Instructions and data can also be sent and received over a network via a network interface device, which can employ any known transmission protocol.

[0129] The memory 501 may be integrated with the processor 502, for example, by arranging RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 501 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 501 and the processor 502 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 502 to read files stored in the memory.

[0130] In addition, electronic device 500 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of electronic device 500 can be interconnected via a bus and / or network.

[0131] According to exemplary embodiments of this disclosure, a computer-readable storage medium may also be provided, which, when executed by a processor of an electronic device, enables the electronic device to perform the thread scheduling method described above. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0132] According to exemplary embodiments of the present disclosure, a computer program product may also be provided, including a computer program that, when executed by a processor, implements the thread scheduling method according to the present disclosure.

[0133] According to the thread scheduling method, apparatus, electronic device, storage medium, and program product disclosed herein, the types of threads waiting for GPU completion events can be distinguished. Furthermore, the awakened threads waiting for GPU completion events can be scheduled according to the respective scheduling strategies corresponding to each type of thread, enabling differentiated scheduling for different types of threads waiting for GPU completion events. This ensures that latency-sensitive threads waiting for GPU completion events are scheduled promptly, while latency-insensitive threads are not unnecessarily prioritized, resulting in more balanced thread scheduling and better scheduling performance.

[0134] According to exemplary embodiments of this disclosure, by distinguishing the types of threads waiting for GPU completion events, wake-up and scheduling strategies can be flexibly configured according to different application scenarios, which can meet both low latency requirements and overall system performance.

[0135] According to exemplary embodiments of this disclosure, by setting a synchronization wake-up flag and / or latency-sensitive hint for threads waiting for GPU completion events of low-latency interaction type, these threads can be selected by the scheduler more quickly, thereby effectively reducing tail latency. It should be noted that, for threads waiting for GPU completion events of low-latency interaction type, an anti-migration flag can also be generated to ensure that these threads are scheduled as close as possible to the original CPU on which they submitted the GPU completion event, thereby reducing cross-CPU migration.

[0136] According to an exemplary embodiment of this disclosure, for batch-type threads waiting for GPU completion events, group scheduling can be performed by adopting a batch scheduling strategy to avoid wake-up storms while ensuring low latency requirements. This avoids CPU preemption storms and sudden increases in the runnable queue caused by a large number of threads being woken up at the same time. The runnable queue can refer to a queue of threads that are ready to run but have not yet been allocated CPU.

[0137] According to an exemplary embodiment of this disclosure, when the current time is close to the scheduling deadline, it indicates that the scheduling requirement for the corresponding threads waiting for GPU completion events is imminent. Therefore, at this time, the scheduling priority of the corresponding threads waiting for GPU completion events can be increased, thereby ensuring that the corresponding threads waiting for GPU completion events can be scheduled first, thus guaranteeing the timeliness of scheduling.

[0138] According to exemplary embodiments of this disclosure, by allocating a local CPU to the awakened target thread, the number of CPU threads migrating between CPUs can be reduced, thereby reducing cross-CPU migration overhead.

[0139] According to an exemplary embodiment of this disclosure, by allocating a CPU in the same cluster to the awakened target thread, the migration of threads waiting for GPU completion events between different nodes can be avoided, thereby effectively reducing cross-node migration overhead.

[0140] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0141] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A thread scheduling method, characterized in that, include: In response to the wake-up of a target thread, the type of the target thread is identified, wherein the target thread is a thread submitted by the central processing unit (CPU) waiting for the graphics processing unit (GPU) to complete an event. The threads waiting for the GPU to complete the event are pre-classified according to the degree of low latency requirement. Different scheduling strategies are pre-assigned to different types of threads waiting for the GPU to complete the event, wherein the scheduling strategy includes a scheduling priority, and the scheduling priority is positively correlated with the degree of low latency requirement of the thread. Allocate CPU time to the target thread according to the scheduling policy corresponding to the type of the target thread; The target thread is executed using the allocated CPU.

2. The thread scheduling method as described in claim 1, characterized in that, Before identifying the type of the target thread in response to it being awakened, the method further includes: A GPU wait context is established in the operating system kernel, wherein the GPU wait context is used to describe the attributes of the target thread, and the GPU wait context includes the type of the target thread; The step of identifying the type of the target thread in response to the target thread being awakened includes: In response to the target thread being awakened, the type of the target thread is read from the established GPU wait context.

3. The thread scheduling method as described in claim 2, characterized in that, The GPU wait context also includes the scheduling deadline of the target thread; The thread scheduling method further includes: Read the scheduling deadline from the established GPU wait context; The step of allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: If the current time is less than the read scheduling deadline than the preset target duration, increase the scheduling priority of the awakened target thread; Based on the increased scheduling priority, CPU is allocated to the target thread according to the scheduling policy corresponding to the type of the target thread.

4. The thread scheduling method as described in claim 1, characterized in that, The step of allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: If the target thread is of the low-latency interactive type, a low-latency scheduling strategy is used to allocate CPU to the target thread; If the target thread is of batch processing type, a batch scheduling strategy is used to allocate CPU to the target thread; If the target thread is of a normal type, a normal scheduling strategy is used to allocate CPU to the target thread; Among them, the low-latency interaction type, the batch processing type, and the normal type have decreasing requirements for low latency in that order, and the scheduling timeliness of the low-latency scheduling strategy, the batch scheduling strategy, and the normal scheduling strategy in that order also decreases in that order.

5. The thread scheduling method as described in claim 4, characterized in that, When the target thread is of a low-latency interactive type, the step of allocating CPU to the target thread using a low-latency scheduling strategy includes: If the target thread is of the low-latency interaction type, generate a synchronous wake-up flag and / or a latency-sensitive prompt. The awakened target thread sends the synchronization wake-up flag and / or the delay-sensitive prompt to the scheduler. The scheduler allocates CPU to the awakened target thread within a preset first duration based on the synchronization wake-up flag, and / or allocates CPU to the awakened target thread for a usage time of up to a preset second duration based on the latency sensitivity prompt.

6. The thread scheduling method as described in claim 4, characterized in that, When the target thread is of batch processing type, the step of allocating CPU to the target thread using a batch scheduling strategy includes: If the target thread is of the batch processing type, determine whether the current batch scheduling cycle has ended; If it is determined that the current batch scheduling cycle has not yet ended, the target thread to be awakened is added to the thread aggregation queue; When the current batch scheduling cycle ends, at least one thread in the thread aggregation queue is submitted to the scheduler; The scheduler allocates CPU time to the at least one thread.

7. The thread scheduling method as described in claim 4, characterized in that, When the target thread is of a normal type, the step of allocating CPU to the target thread using a normal scheduling strategy includes: If the target thread is of the normal type, determine whether the current fair scheduling period has ended; If it is determined that the current fair scheduling period has not yet ended, the target thread to be awakened is added to the fair scheduling queue; If the current fair scheduling period ends, at least one thread in the fair scheduling queue will be submitted to the scheduler. The scheduler allocates CPU time slices to the at least one thread on an equal basis.

8. The thread scheduling method as described in claim 1, characterized in that, The step of allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: According to the scheduling policy corresponding to the type of the target thread, a local CPU is allocated to the awakened target thread, wherein the local CPU is the CPU of the target thread that submitted the event waiting for the GPU to complete.

9. The thread scheduling method as described in claim 1, characterized in that, The step of allocating CPU to the target thread according to the scheduling policy corresponding to the type of the target thread includes: According to the scheduling policy corresponding to the type of the target thread, a cluster CPU is allocated to the awakened target thread. The cluster CPU is a CPU that is in the same non-consistent memory access node as the local CPU. The local CPU is the CPU of the target thread that submitted the waiting for the GPU to complete the event.

10. A thread scheduling device, characterized in that, include: A type identification module is configured to identify the type of a target thread in response to the target thread being awakened, wherein the target thread is a thread submitted by the central processing unit (CPU) waiting for the graphics processing unit (GPU) to complete an event, the threads waiting for the GPU to complete the event are pre-classified according to the degree of low latency requirement, and different scheduling strategies are pre-assigned to different types of threads waiting for the GPU to complete the event, wherein the scheduling strategy includes a scheduling priority, and the scheduling priority is positively correlated with the degree of low latency requirement of the thread; The allocation module is configured to allocate CPU to the target thread according to the scheduling policy corresponding to the type of the target thread; The execution module is configured to execute the target thread using the allocated CPU.

11. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the thread scheduling method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the thread scheduling method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the thread scheduling method as described in any one of claims 1 to 9.

Images