Interrupt scheduling method, electronic device, and storage medium

Abstract

The application relates to the field of operating systems, in particular to an interrupt scheduling method, an electronic device and a storage medium. The method comprises the following steps: acquiring a first delay threshold value, the first delay threshold value being a maximum value of scheduling delay caused by interrupt processing configured for a first processor core; acquiring a scheduling delay value of the first processor core, the scheduling delay value being used for indicating the current interrupt load of the first processor core; and in the case that the scheduling delay value is greater than the first delay threshold value, migrating and binding part of the current interrupt requests of the first processor core to a second processor core. According to the embodiment of the application, the first delay threshold value is configured for the first processor core, so that in the case that the scheduling delay value of the first processor core is greater than the first delay threshold value, part of the current interrupt requests of the first processor core are migrated and bound to the second processor core, and the reasonable interrupt processing throughput can be ensured on the basis of guaranteeing the scheduling delay.

Description

Technical Field

[0001] This application relates to the field of operating systems, and more particularly to an interrupt scheduling method, electronic device, and storage medium. Background Technology

[0002] In the telecommunications field, the Linux operating system is increasingly being used to process high real-time services.

[0003] Please refer to Figure 1 This diagram illustrates an architecture for handling high real-time tasks using the Linux operating system, as described in related technologies. The architecture comprises a hardware layer 120, a kernel layer 140, and a user layer 160. The user layer 160 can run at least one thread, each dedicated to processing tasks. The task scheduling and interrupt handling processes for each thread are primarily implemented by the kernel layer 140.

[0004] Current interrupt handling strategies mainly include two possible implementation methods. One possible implementation is interrupt leveling, which sends interrupt requests (IRQs) relatively evenly to each processor (Central Processing Unit, CPU) core. This method can guarantee interrupt handling throughput, but it cannot solve the problem of uncontrollable scheduling latency caused by interrupt handling. The other possible implementation is interrupt core binding, such as pre-binding network card interrupt requests to a specific processor core, making the scheduling latency on other processor cores controllable. However, this method may result in excessive interrupt load on the bound processor core, increasing the frequency of the entire cluster and causing wasted power. Currently, there is no reasonable and effective interrupt scheduling method that can guarantee reasonable interrupt handling throughput while ensuring scheduling latency. Summary of the Invention

[0005] In view of this, embodiments of this application propose an interrupt scheduling method, an electronic device, and a storage medium. Embodiments of this application use the maximum value of the scheduling delay caused by interrupt handling configured for the first processor core, i.e., a first delay threshold, to ensure that when the scheduling delay value of the first processor core exceeds the first delay threshold, some interrupt requests of the first processor core are migrated and bound to the second processor core. This ensures reasonable interrupt handling throughput while maintaining scheduling delay.

[0006] In a first aspect, embodiments of this application provide an interrupt scheduling method, the method comprising:

[0007] Obtain a pre-configured first latency threshold, which is the maximum scheduling latency caused by interrupt handling configured for the first processor core;

[0008] Obtain the scheduling delay value of the first processor core, the scheduling delay value being used to indicate the current interrupt load of the first processor core;

[0009] If the scheduling delay value is greater than the first delay threshold, some interrupt requests of the first processor core are migrated and bound to the second processor core, which is different from the first processor core.

[0010] In this implementation, the present application embodiment uses the maximum value of the scheduling delay caused by the interrupt handling configured for the first processor core, namely the first delay threshold, so that when the scheduling delay value of the first processor core is greater than the first delay threshold, some interrupt requests of the first processor core are migrated and bound to the second processor core. This ensures that the scheduling delay caused by interrupt handling on the first processor core is controllable, avoids the problem of excessive scheduling delay caused by interrupt handling in related technologies, ensures the real-time performance of the service processing, and improves the overall performance of the electronic device.

[0011] In one possible implementation, the scheduling latency of the first processor core after the migration binding is less than or equal to the first latency threshold.

[0012] In this implementation, if the current scheduling latency of the first processor core is greater than the first latency threshold, then some interrupt requests of the first processor core are migrated and bound to the second processor core, so that the scheduling latency of the first processor core after migration and binding is less than or equal to the first latency threshold, thereby reducing the scheduling latency on the first processor core and further ensuring the real-time performance of the business processing.

[0013] In another possible implementation, the absolute value of the difference between the scheduling latency values ​​of other processor cores after the migration binding is less than a preset first difference threshold, and the other processor cores are all processor cores other than the first processor core.

[0014] In this implementation, the migration of some interrupt requests is reasonably distributed across other processor core clusters, so that the absolute value of the difference between the scheduling latency values ​​of other processor cores after migration and binding is less than a preset first difference threshold. This ensures the concurrency of interrupt processing and avoids the problem of excessive load on a single processor core raising the frequency of the entire cluster and causing power waste.

[0015] In another possible implementation, the method is used in an electronic device comprising a user layer, a kernel layer, and a hardware layer, wherein obtaining a pre-configured first latency threshold includes:

[0016] The user layer sends first configuration information to the kernel layer, the first configuration information including the processor core identifier of the first processor core and the first latency threshold;

[0017] The kernel layer receives the first configuration information sent by the user layer;

[0018] When the scheduling delay value is greater than the first delay threshold, migrating and binding a portion of the current interrupt requests of the first processor core to the second processor core includes:

[0019] If the scheduling delay value is greater than the first delay threshold, the kernel layer sends second configuration information to the interrupt controller of the hardware layer. The second configuration information includes the interrupt number to be migrated out in the first processor core and the processor core identifier of the second processor core.

[0020] The interrupt controller migrates and binds at least one interrupt request corresponding to the interrupt number to the second processor core according to the second configuration information.

[0021] In this implementation, the kernel layer dynamically adjusts the interrupt binding based on the current scheduling latency value of the first processor core and the first latency threshold configured by the user layer. If the current scheduling latency value of the first processor core is greater than the first latency threshold, the kernel layer sends second configuration information to the interrupt controller of the hardware layer. This allows the interrupt controller to migrate and bind at least one interrupt request corresponding to the interrupt number to the second processor core based on the second configuration information. This further ensures that the scheduling latency caused by interrupt processing on the first processor core is controllable and improves the overall performance of the electronic device.

[0022] In another possible implementation, the method further includes:

[0023] Upon receiving an interrupt request, the interrupt processing duration corresponding to the interrupt request is obtained, and the interrupt processing duration includes the total duration of hardware interrupt processing and software interrupt processing.

[0024] Based on the interrupt processing duration of the interrupt request, a preset algorithm is used to determine the scheduling delay value corresponding to the interrupt request;

[0025] The scheduling delay value corresponding to the interrupt request is summed with the current scheduling delay value of the first processor core to obtain the updated scheduling delay value.

[0026] In this implementation, compared with the related technologies that calculate the scheduling latency cost based on the processor core dimension, this application embodiment tracks and calculates the load cost of each interrupt request, thereby avoiding the coarse algorithm that can only calculate the load based on the number of interrupts in the past. This supports more accurate interrupt balancing processing, and includes the time cost of soft interrupt processing triggered by hard interrupt processing in the corresponding interrupt processing duration. This makes the scheduling latency value determined based on the interrupt processing duration more accurate, so that interrupt balancing processing can be performed more accurately in the future.

[0027] In another possible implementation, the method further includes:

[0028] Obtain the pre-configured second delay threshold, which is the maximum scheduling delay caused by interrupt handling configured for the specified thread;

[0029] After the specified thread is awakened, the processor core that meets the preset core selection conditions is determined as the target processor core. The preset core selection conditions include that the current scheduling latency value of the processor core is less than or equal to the second latency threshold.

[0030] Add the specified thread to the scheduling queue of the target processor core.

[0031] In this implementation, when selecting a core for a task, the task scheduling latency requirement and the processor core's scheduling latency value are considered. Only when the current scheduling latency value of the processor core is less than or equal to the second latency threshold of the task scheduling latency requirement can the processor core be selected as the target processor core, ensuring that the critical specified thread can be selected on the processor core with the low scheduling latency value and be scheduled in a timely manner.

[0032] In another possible implementation, the designated thread includes the foreground application's frame-drawing process and / or the process of the inter-process communication mechanism.

[0033] This implementation supports configuring scheduling latency requirements at the task granularity, distinguishing between foreground and background threads, and reducing the impact of background threads on specified foreground threads.

[0034] Secondly, embodiments of this application provide an electronic device, the electronic device comprising:

[0035] processor;

[0036] Memory used to store processor-executable instructions;

[0037] The processor is configured to implement the method provided by the first aspect or any possible implementation of the first aspect when executing the instructions.

[0038] Thirdly, embodiments of this application provide a non-volatile computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the method provided by the first aspect or any possible implementation thereof.

[0039] Fourthly, an interrupt scheduling apparatus is provided, the apparatus comprising at least one unit for implementing the method provided in the first aspect or any possible implementation thereof.

[0040] Fifthly, embodiments of this application provide a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in an electronic device, a processor in the electronic device executes the method provided by the first aspect or any possible implementation thereof. Attached Figure Description

[0041] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this application together with the specification and serve to explain the principles of this application.

[0042] Figure 1 This diagram illustrates an architecture in the related technology that uses the Linux operating system to handle high real-time business.

[0043] Figure 2 A schematic diagram of five scheduling classes in the Linux kernel is shown in the relevant technology.

[0044] Figure 3 A schematic diagram of the scheduling queue of a processor core in the related art is shown.

[0045] Figure 4 This diagram illustrates the architecture of interrupt handling in the Linux operating system within the relevant technologies.

[0046] Figure 5a This diagram illustrates the interrupt handling time of multiple processor cores when interrupt leveling is employed.

[0047] Figure 5b This diagram illustrates the interrupt handling time of multiple processor cores when interrupt binding is used.

[0048] Figure 6 A schematic diagram of an electronic device according to an embodiment of this application is shown.

[0049] Figure 7 A flowchart of an interrupt scheduling method provided in an exemplary embodiment of this application is shown.

[0050] Figure 8 A flowchart illustrating the process of scheduling delay value statistics provided in an exemplary embodiment of this application is shown.

[0051] Figure 9 A flowchart of a task selection process provided in an exemplary embodiment of this application is shown.

[0052] Figure 10 A schematic diagram of the interface involved in the interrupt scheduling method provided by another exemplary embodiment of this application is shown.

[0053] Figure 11 A flowchart of an interrupt scheduling method provided by another exemplary embodiment of this application is shown.

[0054] Figure 12 This illustration shows a schematic diagram of the scheduling latency of a specified thread provided by an exemplary embodiment of this application.

[0055] Figure 13 A flowchart of an interrupt scheduling method provided by another exemplary embodiment of this application is shown.

[0056] Figure 14 A block diagram of an interrupt scheduling apparatus provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0057] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0058] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0059] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.

[0060] First, some terms used in the embodiments of this application will be introduced.

[0061] 1. Process: A process is an entity of a program in execution. In addition to the executed code, it also includes information such as open files and pending signals.

[0062] 2. Threads: A process can include multiple threads, which share the same address space.

[0063] 3. Task: A kernel (the core of the operating system) scheduling object, which can be a process or a thread. For example, the Linux kernel uses the `task_struct` structure to describe processes and threads.

[0064] 4. Scheduling Queues: A processor core includes at least one scheduling queue. After a task is woken up, it is added to the scheduling queue of a processor core to await scheduling. Optionally, the task will be added to one of the following scheduling queues in that processor core according to the scheduling policy: Deadline Runqueue (dl_rq), RealTime Runqueue (rt_rq), or Completely Fair Runqueue (cfs_rq).

[0065] Optionally, each processor core includes a process queue (Runqueue, rq) to manage the dl_rq, rt_rq, and cfs_rq within that processor core. All DL tasks must be added to the dl_rq for scheduling before execution, all RT tasks must be added to the rt_rq for scheduling, and all CFS tasks must be added to the cfs_rq for scheduling.

[0066] 5. Scheduling latency: The time from when a task is woken up and added to the scheduling queue to when it actually begins execution. In real-time systems, scheduling latency can be as low as microseconds (µs).

[0067] 6. Context Switching: Switching between kernel running states, and / or switching tasks on the processor core. For example, the Linux kernel includes the following running states: user mode, kernel mode (running in process context), and kernel mode (running in interrupt context). Switching between these running states, as well as switching between tasks, is called context switching. Context switching incurs overhead because it requires saving and restoring state information such as registers and page tables.

[0068] 7. Preemption: After a high-priority task is woken up, if the currently executing task has a lower priority, the currently executing task will be immediately switched to the high-priority task. In this way, the high-priority task can be executed as quickly as possible, with lower scheduling latency.

[0069] 8. Disable preemption: Disable the preemption capability mentioned above. This is because the kernel needs to avoid concurrency competition introduced by preemption when processing certain critical resources.

[0070] 9. Throughput: The amount of data processed by the system per unit of time. It reflects the system's data processing capability. It is usually negatively correlated with the number of context switches; that is, the more context switches, the lower the throughput; conversely, the fewer context switches, the higher the throughput.

[0071] 10. Interrupt: During the execution of an electronic device, any unusual or unexpected event requiring urgent processing occurs within the system, causing the processor to temporarily suspend the currently executing program and execute the corresponding event handler. After processing is complete, execution returns to the point of interruption or a new process is scheduled for execution. The event that causes an interrupt is called an interrupt source. The interrupt source sends a signal to the processor requesting interrupt processing; this is called an interrupt request. The process by which the processor processes the interrupt request is called interrupt handling.

[0072] The scheduling subsystem is one of the core modules in the Linux kernel. It is used for task scheduling, such as determining tasks to be executed, their start time, and execution duration. The current Linux kernel defines five scheduling classes, such as... Figure 2 As shown, the five scheduling classes are: STOP scheduling class, Deadline-oriented (DL) scheduling class, Real-Time (RT) scheduling class, Completely Fair Scheduler (CFS) scheduling class, and Idle scheduling class. STOP and Idle are two special scheduling classes that are not used to schedule ordinary tasks.

[0073] Within the scheduling classes, there is a priority order. For example, if both the RT (Real-Time) and CFS (Concurrent-Time) scheduling classes have tasks waiting to be scheduled, the kernel will first select a task from the RT scheduling class's queue for execution. Only after all tasks in the RT scheduling class have completed execution, voluntarily yielded the processor core (e.g., to sleep), or the RT task's runtime exceeds a pre-configured duration threshold, will a task in the CFS scheduling class be scheduled for execution. In some systems (such as Android), the RT and CFS scheduling classes handle most of the tasks in the operating system.

[0074] CFS (Complete Free) scheduling is the default scheduling algorithm in the Linux kernel. This algorithm emphasizes ensuring scheduling fairness, guaranteeing that all processes will be scheduled within a certain time. However, precisely because of its fairness, even if a task has the highest priority, it cannot be guaranteed that the task will always be scheduled for execution first (even setting the nice value to -20 does not guarantee this). In other words, scheduling latency is uncontrollable.

[0075] RT (Real-Time) scheduling is a algorithm that strictly follows priority. When a task is woken up, if its priority is higher than that of the currently running task, it will preempt the currently running task, allowing the processor core to immediately switch to execute the woken-up high-priority task, thus ensuring the scheduling latency of the high-priority task. To ensure timely rendering (for example, a 60fps phone needs to complete the rendering of one frame in 16.7ms), it is necessary to strictly control the scheduling latency of designated threads such as the UI / Render thread and the Surfaceflinger thread. If the scheduling latency is too high, it will cause stuttering because there is not enough time to render frames. Therefore, the system will identify these designated threads and configure them as RT tasks.

[0076] In an illustrative example, the processor core scheduling queue is as follows: Figure 3 As shown in the diagram. The parameter `prio` indicates the normalized priority of the task, with a value ranging from [0, 139]. When the value of `prio` is in the range of [100, 139], it indicates that the task is managed by the CFS scheduling class; when the value of `prio` is in the range of [0, 99], it indicates that the task is managed by the RT scheduling class. The value of the parameter `prio` is negatively correlated with the priority of the task; that is, the lower the value of `prio`, the higher the priority of the task. For example, if the `prio` parameter of task 1 is 97 and the `prio` parameter of task 2 is 98, then the priority of task 1 is higher than the priority of task 2. Figure 3 In the current scheduling queue of processor core 0 (referred to as core 0), tasks A (prio=98) managed by the RT scheduling class, X (prio=120) managed by the CFS scheduling class, and Y (prio=120) managed by the CFS scheduling class are listed in execution order. After task B (prio=97) managed by the RT scheduling class is woken up, in one possible implementation, if preemption of low-priority tasks by high-priority tasks is supported, core 0 immediately switches the currently executing task A to the high-priority task B. After the switch, the scheduling queue of core 0, in execution order, includes task B, task A, task X, and task Y. In another possible implementation, if preemption is not supported (i.e., preemption is disabled), the high-priority task B cannot be scheduled immediately. After task B is woken up, it is only added to the scheduling queue, and the currently executing task remains task A. In this case, the scheduling queue of core 0, in execution order, includes task A, task B, task X, and task Y.

[0077] In related technologies, interrupt handling disables preemption to prevent concurrency. During this process, if the SurfaceFlinger thread is added to the scheduling queue, it cannot be scheduled immediately due to disabled preemption. It typically waits for a period of time (e.g., 4ms) before being scheduled for execution, ultimately resulting in insufficient time for rendering and dropped frames. Under conditions of high network traffic (e.g., batch application updates, video downloads), the scheduling latency of soft interrupt handling can even reach 10ms, making similar frame drops and stuttering issues very likely.

[0078] In an illustrative example, a schematic diagram of the interrupt handling architecture in the Linux operating system is shown below. Figure 4 As shown. Interrupts are an asynchronous event handling mechanism used to improve the system's concurrent processing capabilities. When an interrupt request occurs, it triggers the execution of an interrupt handler, which is divided into two parts: the upper half and the lower half. The upper half corresponds to hardware interrupts and is used to quickly handle interrupts. For example, the processor core calls the registered interrupt function according to the interrupt table, and this interrupt function calls the corresponding function in the driver. The lower half corresponds to software interrupts and is used to asynchronously handle the work not completed in the upper half. The ksoftirqd process in the Linux kernel is specifically responsible for handling software interrupts. When it receives a software interrupt, it calls the corresponding handling function, such as the net_rx_action function. Currently, the main reason why the Surfaceflinger thread cannot be scheduled in a timely manner is that preemption is disabled for both the upper and lower half of the interrupt handling, and the lower half of the interrupt handling is time-consuming. By the time the lower half of the interrupt handling is completed and preemption is enabled, the Surfaceflinger thread will be scheduled for execution, but it will be too late to complete the frame drawing. To address the aforementioned issues, one approach in related technologies is to thread interrupt handling, allowing it to be preempted and thus ensuring that high-priority tasks are scheduled promptly, effectively reducing scheduling latency. One possible implementation involves a set of real-time patches maintained outside the Linux mainline (such as the PREEMPT_RT patch). These patches thread the kernel's interrupt handling and allow the interrupt handling thread to be preempted by high-priority tasks. This prevents high-priority tasks from being unable to be scheduled due to interrupt handling, thereby reducing scheduling latency caused by interrupt handling.

[0079] However, the above method has the following problems: On the one hand, the preemption of high-priority tasks will cause a delay in the original interrupt handling. For example, the clock interrupt handling that should be triggered at 100ms will be executed at 105ms, which will cause a 5ms deviation in the timer, thus affecting other business processes / threads. On the other hand, the preemption of interrupt threads will introduce task context switching. Switching has performance overhead, and frequent switching will lead to a decrease in system throughput.

[0080] To address the aforementioned issues, another approach in related technologies is interrupt binding, which involves binding interrupt handling to a target processor core, which is at least one pre-defined processor core. Based on the processor core load, a specified thread is scheduled to other processor cores besides the target processor core. This makes the number of interrupts on other processor cores controllable, and the scheduling latency controllable, preventing excessive scheduling latency.

[0081] In an illustrative example, the electronic device includes eight processors (cores 0 to 7), such as... Figure 5a As shown, the interrupt handling strategy employed is interrupt leveling, where interrupt processing is roughly amortized across each processor core. This means that the interrupt processing time (in microseconds) for each processor core is approximately the same. Under this strategy, interrupt processing may migrate back and forth, leading to uncontrollable scheduling latency. However... Figure 5b In this system, the interrupt handling strategy adopted is core-bound interrupt handling, such as binding interrupt handling to cores 0 and 4 (other processor cores still have interrupt load because some interrupt requests cannot be bound to cores, such as clock interrupts). By scheduling specified threads to processor cores other than cores 0 and 4 based on the processor core load, the scheduling latency can be controlled.

[0082] However, the above method has the following problems: 1. It will cause interrupt handling to be concentrated on the target processor core (e.g., Figure 5b 1. In the case of cores 0 and 4, the frequency of the entire cluster is increased, resulting in wasted power consumption (while other processor cores in the cluster have low loads but high frequencies); 2. Similarly, because interrupt handling is concentrated on the target processor core, other processor cores will not process interrupts even if they are idle, resulting in low system throughput; 3. Before interrupt binding, it is often necessary to evaluate the load of each peripheral interrupt and bind interrupts reasonably according to the load. This method lacks flexibility. If a new peripheral is added, the interrupt allocation needs to be re-evaluated, and sometimes the original interrupts need to be re-planned and bound.

[0083] To address these issues, this application provides an interrupt scheduling method, an electronic device, and a storage medium to solve the problems existing in the related technologies. In the technical solution provided by this application, the maximum value of the scheduling delay caused by interrupt processing configured for the first processor core is defined as a first delay threshold. This ensures that if the scheduling delay value of the first processor core exceeds the first delay threshold, some interrupt requests currently belonging to the first processor core are migrated and bound to the second processor core. This guarantees that the scheduling delay caused by interrupt processing on the first processor core is controllable, avoids the problem of excessive scheduling delay caused by interrupt processing in related technologies, ensures the real-time performance of the service processing, and improves the overall performance of the electronic device.

[0084] Before explaining the embodiments of this application, the application scenarios of these embodiments will be described first. Please refer to... Figure 6 The diagram illustrates an electronic device according to an embodiment of this application. The electronic device includes a hardware layer 610, a kernel layer 620, and a user layer 630. The user layer 630 can run at least one thread, each thread being used to process tasks. The task scheduling and interrupt response processes for each thread are primarily implemented by the kernel layer 620.

[0085] Among them, the hardware layer 610 is the hardware foundation of the electronic device. This electronic device can be a base station device, transmission equipment, industrial robot, or other electronic device that requires real-time task processing. For example, if the electronic device is a mobile phone, the interrupt scheduling method provided in this application embodiment can be applied to application scenarios requiring rapid response, such as autonomous driving, industrial control, and virtual reality (VR) technology. Combined with the configuration of business processes, it can reduce task scheduling latency and ensure that critical tasks can be scheduled in a timely manner.

[0086] The hardware layer 610 includes peripheral devices 612, an interrupt controller 614, and at least one processor 616. Peripheral devices 612 include wireless network cards, Bluetooth devices, etc. The processor 616 can be a single-core processor or a multi-core processor.

[0087] When the peripheral device 612 is processing data (such as wireless network card sending and receiving packets), it generates an interrupt request and routes it to one of the multiple processor cores through the interrupt controller 614.

[0088] Kernel layer 620 is the layer containing the operating system kernel, virtual memory space, and drivers for application execution. For example, the operating system kernel is the Linux kernel.

[0089] The kernel layer 620 includes an interrupt subsystem 622 and a scheduling subsystem 624. The interrupt subsystem 622 includes an interrupt handling module 640, an interrupt load collection module 641, an interrupt load calculation module 642, an interrupt load information statistics module 643, an interrupt load policy module 644, and an interrupt load balancing execution module 645. The scheduling subsystem 624 includes a specified thread configuration module 651, a task core selection policy module 652, and a task scheduling execution module 653.

[0090] Interrupt handling module 640 obtains an interrupt request from the processor core and begins interrupt handling in interrupt subsystem 622, which includes hardware interrupt handling and software interrupt handling.

[0091] The interrupt load collection module 641 records the interrupt processing duration and sends it to the interrupt load calculation module 642. The interrupt processing duration includes the total duration of hardware interrupt processing and software interrupt processing.

[0092] The interrupt load calculation module 642 determines the scheduling delay value of the current processor core using a preset algorithm based on the interrupt processing duration provided by the interrupt load collection module 641. The calculation result is in µs or ns.

[0093] The interrupt load information statistics module 643 stores and summarizes the scheduling delay information on the processor core. The scheduling delay information includes the summary information of the scheduling delay values ​​of each interrupt request on the processor core.

[0094] The interrupt load balancing strategy module 644 obtains the first latency threshold configured by the user layer 630 for the first processor core and makes a decision based on the scheduling latency information stored in the interrupt load information statistics module 643 and the first latency threshold. When the scheduling latency value of the first processor core is greater than the pre-configured first latency threshold, a core binding strategy is determined and sent to the interrupt load balancing execution module 645. This core binding strategy instructs some interrupt requests to be offloaded and bound to other second processor cores, thereby ensuring that the scheduling latency value of the first processor core is less than the first latency threshold.

[0095] The interrupt load balancing execution module 645 receives the core binding policy from the interrupt load policy module 644, operates the interrupt controller 614 according to the core binding policy, and binds the corresponding interrupt request to the second processor core.

[0096] The scheduling subsystem 624 is responsible for scheduling and executing all processes / threads in the system.

[0097] The specified thread configuration module 651 supports configuring a second delay threshold for a specified thread.

[0098] The task core selection strategy module 652 is used to check the interrupt load of the first processor core in the task core selection process. When the scheduling delay value is less than or equal to the second delay threshold, the corresponding processor core is considered to meet the condition and is further screened as the second processor core.

[0099] The task scheduling and execution module 653 is used to add processes / threads to the scheduling queue of the corresponding processor core. Since the interrupt load of the processor core has been checked in the previous step, it can be assumed that the corresponding process / thread can be scheduled and executed within a certain period of time.

[0100] User layer 630 is the layer where ordinary applications run. For example, the user layer includes an application framework layer (such as the Framework layer). User layer 630 includes an interrupt load management module 632 and a designated thread identification / management module 634.

[0101] User layer 630 is responsible for configuring the first latency threshold of the first processor core, as well as the identification and configuration of specified threads.

[0102] The interrupt load management module 632 is responsible for monitoring the overall interrupt load of the system. When the interrupt load of a certain processor core is too high, it selects a suitable second processor core (for example, selects a processor core with a lighter current interrupt load to reduce interrupt migration) and configures a first latency threshold for that processor core to ensure that there is at least one processor core with controllable interrupt load in each cluster.

[0103] The designated thread identification / management module 634 is responsible for identifying the thread (such as UI / Render) responsible for drawing frames in the user layer 630 and configuring a second latency threshold for it.

[0104] It should be noted that the functions implemented by the above-mentioned functional modules can be referred to the relevant descriptions in the method embodiments below, and will not be described here. Furthermore, the electronic device provided in the above embodiments is only illustrated by the division of the above-mentioned functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the electronic device can be divided into different functional modules to complete all or part of the functions described above.

[0105] The interrupt scheduling method provided in this application will now be described using several exemplary embodiments.

[0106] Please refer to Figure 7 This document illustrates a flowchart of an interrupt scheduling method provided in an exemplary embodiment of this application. The embodiments of this application apply this interrupt scheduling method to... Figure 6 The interrupt scheduling method is illustrated using an example of an electronic device.

[0107] Step 701: The user layer configures the first latency threshold of the first processor core and sends the first configuration information to the kernel layer.

[0108] Optionally, the user layer determines at least one processor core within the electronic device as the first processor core, and the maximum scheduling latency caused by the interrupt handling configured for the first processor core is the first latency threshold. The user layer sends the first configuration information to the kernel layer.

[0109] Indicatively, the first processor core is a single processor core, and the first configuration information includes the processor core identifier and a first latency threshold. Alternatively, the first processor core may be at least two processor cores, and the first configuration information includes at least two processor core identifiers and their respective corresponding first latency thresholds. The first latency thresholds corresponding to the at least two processor core identifiers may be the same or different. This application does not limit the scope of the embodiments; for ease of explanation, only the example of a single processor core is used.

[0110] The processor core identifier is used to uniquely identify the first processor core among multiple processor cores in the electronic device, and the first latency threshold is the maximum scheduling latency caused by the interrupt handling configured for the first processor core. This first latency threshold can be dynamically adjusted subsequently based on the scheduling latency values ​​within each processor core and / or the frame completion status.

[0111] Step 702: The kernel layer determines whether the scheduling latency value of the first processor core is greater than the first latency threshold based on the first configuration information.

[0112] Correspondingly, the kernel layer receives the first configuration information sent by the user layer, which includes the processor core identifier of the first processor core and the first latency threshold.

[0113] Optionally, when the kernel layer receives the first configuration information sent by the user layer or updates the scheduling latency value of each processor core, it determines whether the scheduling latency value of the first processor core is greater than the first latency threshold. If the current scheduling latency value of the first processor core is less than or equal to the first latency threshold, the process of this embodiment ends. If the scheduling latency value of the first processor core is greater than the first latency threshold, step 703 is executed.

[0114] The scheduling latency value of the first processor core is used to indicate the current interrupt load of the first processor core. Optionally, the scheduling latency value is positively correlated with the interrupt load, that is, the higher the interrupt load, the higher the scheduling latency value.

[0115] Optionally, the scheduling latency value of the first processor core is the actual or estimated value of the current scheduling latency of the first processor core. Illustratively, the scheduling latency value of the first processor core is an estimated value of the scheduling latency determined based on the current interrupt handling duration of the first processor core.

[0116] It should be noted that the process by which the kernel layer determines the scheduling latency value of the first processor core can be referred to the relevant description in the following embodiments, and will not be introduced here.

[0117] Step 703: If the scheduling delay value of the first processor core is greater than the first delay threshold, the kernel layer performs interrupt balancing processing and sends the second configuration information to the interrupt controller.

[0118] If the current scheduling latency value of the first processor core is greater than the first latency threshold, the kernel layer determines the interrupt balancing strategy and sends second configuration information indicating the interrupt balancing strategy to the interrupt controller. Optionally, the kernel layer sends the second configuration information to the interrupt controller through the scheduling latency value balancing execution module.

[0119] The interrupt balancing strategy indicated by the second configuration information is to migrate and bind some of the current interrupt requests of the first processor core to the second processor core. The second processor core is different from the first processor core. After migration and binding, the scheduling latency value of the first processor core is less than or equal to the first latency threshold.

[0120] Optionally, the second configuration information includes the interrupt numbers to be migrated from the first processor core and the processor core identifier of the second processor core. Illustratively, the interrupt numbers to be migrated are m interrupt numbers, where m is a positive integer. Each interrupt number corresponds to at least one interrupt request.

[0121] Schematic, the second configuration information includes the interrupt number to be migrated and the corresponding binding relationship information. The binding relationship information for one of the interrupt numbers indicates the binding relationship between at least one interrupt request corresponding to that interrupt number and a processor core. For example, an electronic device includes 8 processor cores, the interrupt number to be migrated is interrupt number 10, and interrupt number 10 corresponds to multiple interrupt requests. The second configuration information includes interrupt number 10 and information about 8 bits corresponding to interrupt number 10. These 8 bits have a one-to-one correspondence with the 8 processor cores. When a bit is a first value, it indicates that the multiple interrupt requests corresponding to that interrupt number are bound to the processor core corresponding to that bit. When a bit is a second value, it indicates that the multiple interrupt requests corresponding to that interrupt number have no binding relationship with the processor core corresponding to that bit. For example, the first value is 1, and the second value is 0. This application does not limit this aspect.

[0122] Optionally, the first processor currently includes multiple interrupt loads, and there is a one-to-one correspondence between the multiple interrupt loads and multiple interrupt numbers. If the current scheduling latency of the first processor core is greater than a first latency threshold, the kernel layer determines the absolute value of the difference between the current scheduling latency of the first processor core and the first latency threshold as the first difference. The first processor selects at least one interrupt load from the multiple interrupt loads according to a preset algorithm, and determines the interrupt number corresponding to the selected at least one interrupt load as the interrupt number to be migrated out, such that the total scheduling latency corresponding to the interrupt number to be migrated out is greater than the first difference. The interrupt balancing strategy is determined to migrate and bind the interrupt request corresponding to the interrupt number to be migrated out to the second processor core. For example, the preset algorithm is to select interrupt numbers in descending order of interrupt load corresponding to the interrupt number. It should be noted that the preset algorithm can also adopt other possible implementation methods, which are not limited in this embodiment. The second processor core is any processor core other than the first processor core in the electronic device. Optionally, the second processor core is any processor core other than the first processor core. Or, the second processor core is any at least two processor cores other than the first processor core.

[0123] Optionally, the second processor core is at least one processor core other than the first processor core whose scheduling latency value is less than a third latency threshold. Illustratively, the kernel layer iterates through the scheduling latency values ​​of other processor cores and determines the processor core with a scheduling latency value less than the third latency threshold as the second processor core. The third latency threshold can be a user-defined setting or a default setting. This application does not limit this aspect.

[0124] Optionally, the second processor core is at least one processor core with the smallest scheduling latency value other than the first processor core. Illustratively, the kernel layer iterates through the scheduling latency values ​​of other processor cores, sorts the second processor cores according to their scheduling latency values ​​in ascending order, and determines the first n sorted processor cores as the second processor core, where n is a positive integer.

[0125] Step 704: The interrupt controller migrates and binds some of the current interrupt requests of the first processor core to the second processor core according to the second configuration information.

[0126] The interrupt controller receives second configuration information sent by the kernel layer and executes the interrupt balancing strategy indicated by the second configuration information. Specifically, it migrates and binds some interrupt requests from the first processor core to the second processor core. The second processor core is different from the first processor core, and after migration and binding, the scheduling latency of the first processor core is less than or equal to a first latency threshold. The second processor core is at least one processor core other than the first processor core.

[0127] Optionally, the second configuration information includes the interrupt numbers to be migrated from the first processor core and the processor core identifier of the second processor core. The interrupt controller, based on the second configuration information, migrates and binds at least one interrupt request corresponding to the interrupt number to the second processor core. Illustratively, the interrupt numbers to be migrated are m interrupt numbers to be migrated, where m is a positive integer.

[0128] Optionally, the interrupt controller migrates and binds a portion of the current interrupt requests from the first processor core to the second processor core using a preset amortization method. The preset amortization method indicates that the absolute value of the difference between the scheduling latency values ​​of the other processor cores after migration and binding is less than a first difference threshold. Here, the other processor cores refer to all processor cores in the electronic device other than the first processor core, and the first difference threshold is either custom-set or a default setting. This application embodiment does not limit this specific behavior.

[0129] In summary, this embodiment dynamically adjusts interrupt binding at the kernel layer based on the current scheduling latency of the first processor core and the first latency threshold configured at the user layer. If the current scheduling latency of the first processor core is greater than the first latency threshold, the interrupt controller migrates and binds some interrupt requests from the first processor core to the second processor core. This ensures that the scheduling latency of the first processor core is less than or equal to the first latency threshold after migration and binding, thus reducing the scheduling latency on the first processor core. Furthermore, by distributing some of the migrated interrupt requests reasonably across other processor cores in the cluster, the concurrency of interrupt processing is guaranteed, and the excessive load on a single processor core avoids overloading the entire cluster and causing power waste.

[0130] Regarding scheduling latency statistics, the following issues still exist in related technologies: hard interrupt handling and soft interrupt handling are handled separately. Soft interrupt handling is unaware of which hard interrupt handling triggered its execution, and the corresponding scheduling latency values ​​in the kernel are also counted separately.

[0131] In reality, the two are related. For example, during network packet reception, the kernel enters a hard interrupt handler for simple hardware configuration (which takes a short time), and then triggers a soft interrupt handler through the `raise_softirq_irqoff` interface. The actual packet processing is then performed in the handler function of the soft interrupt handler (which takes a longer time). In this scenario, without a hard interrupt handler, a soft interrupt handler would not be triggered, and both should be included in the overhead statistics for the same interrupt number.

[0132] In related technologies, scheduling latency statistics are performed at the processor core level, and load statistics are not supported at the interrupt level. Therefore, some current software that implements interrupt balancing can only evaluate the scheduling latency of a certain interrupt number based on the number of interrupts. However, the processing time of different interrupts is not consistent, so the statistical results are not accurate and cannot well support the interrupt balancing processing in the embodiments of this application. For example, the hardware interrupt processing of a network card itself does not take much time, but its software interrupt processing is relatively time-consuming. If the scheduling latency calculation method in related technologies is used, which does not link the two, it may create the illusion that the interrupt overhead of the network card is small.

[0133] To address the aforementioned issues, this application proposes a Per-Interrupt Load Tracking (PILT) method, which involves calculating scheduling latency based on interrupt requests and including the overhead of corresponding soft interrupt processing in the scheduling latency value of the corresponding interrupt request. Based on this... Figure 7 In the illustrated embodiment, before step 702, where the kernel layer determines whether the scheduling latency value of the first processor core is greater than the first latency threshold, the kernel layer needs to calculate the scheduling latency value of the first processor core. In one possible implementation, the kernel layer performs real-time calculations of the scheduling latency value based on the received interrupt requests. The process of calculating the scheduling latency value includes the following steps: Figure 8 As shown:

[0134] Step 801: Obtain the interrupt processing duration corresponding to the interrupt request. The interrupt processing duration includes the total duration of hardware interrupt processing and software interrupt processing.

[0135] Optionally, upon receiving an interrupt request, the start and end times of the hardware interrupt processing corresponding to the interrupt request are determined, and the absolute value of the difference between the start and end times of the hardware interrupt processing is determined as the first processing duration; the start and end times of the software interrupt processing corresponding to the interrupt request are determined, and the absolute value of the difference between the start and end times of the software interrupt processing is determined as the second processing duration; the sum of the first and second processing durations of the interrupt request is determined as the interrupt processing duration of the interrupt request.

[0136] Optionally, to establish the association between hardware interrupt handling and software interrupt handling, before the hardware interrupt handling of an interrupt request ends and the software interrupt handling is triggered, the interrupt number of the interrupt request and the software interrupt type of the triggered software interrupt handling are saved. The interrupt number of an interrupt request is used to uniquely identify the interrupt request among multiple interrupt requests. Software interrupt types include network receive interrupt, network transmit interrupt, timer interrupt, scheduling interrupt, and Read-CopyUpdate (RCU) lock, etc.

[0137] Optionally, since there may be many hard interrupts being processed at any given time, and soft interrupts may not be able to process them all, it is necessary to save the data in an array. This involves storing the interrupt number of the interrupt request and the soft interrupt type of the triggered soft interrupt in a single array. For example, if an interrupt request has an interrupt number of "200" and a soft interrupt type of network receive interrupt "NET_RX", then "softirq_type:NET_RX; hw_irq:200" would be stored in an array. The soft interrupt handler retrieves the first array member matching the soft interrupt type from the array saved in the previous step. For example, the soft interrupt for network packet reception corresponds to the soft interrupt type "NET_RX," and retrieves the interrupt number from the first array member matching the soft interrupt type "NET_RX." The second processing time of the soft interrupt is then included in the interrupt processing time for that interrupt number.

[0138] For example, if the first processing time for interrupt number 200 is delta_hardirq200 and the second processing time for interrupt number 200 is delta_softirq200, then the interrupt processing time for interrupt number 200 is delta_irq200 = delta_hardirq200 + delta_softirq200.

[0139] Step 802: Based on the interrupt processing duration of the interrupt request, determine the scheduling delay value corresponding to the interrupt request using a preset algorithm.

[0140] Optionally, the preset algorithm includes Per-entity load tracking (PELT) or Window Assisted Load Tracking (WALT).

[0141] In one possible implementation, the WALT algorithm is used. The length of the window is preset (e.g., 10ms). The average or current maximum value of the interrupt handling time within the most recent preset number of windows (e.g., the preset number is 5) is calculated. The average or maximum value obtained is then determined as the scheduling delay value corresponding to the interrupt request.

[0142] For example, using the PELT algorithm, a pre-set attenuation factor is used to weight and sum the interrupt processing times within a preset number of windows. The attenuation factor is a positive number less than 1. For instance, if the attenuation factor is y, and the interrupt processing times within the three windows are 10, 9, and 8 respectively, then the scheduling delay value corresponding to the interrupt request is 10×y + 9×y. 2 +8×y 3 .

[0143] Optionally, the interrupt number and scheduling delay value corresponding to the interrupt request can be saved. For example, the interrupt number and scheduling delay value can be stored in a specified variable of the first processor core, such as a per-processor-core variable.

[0144] Step 803: Sum the scheduling delay value corresponding to the interrupt request with the current scheduling delay value of the first processor core to obtain the updated scheduling delay value.

[0145] Optionally, the scheduling delay value corresponding to the interrupt request is weighted and summed with the current scheduling delay value of the first processor core to obtain the updated scheduling delay value.

[0146] In summary, compared with the related technologies that calculate scheduling latency overhead based on processor cores, the embodiments of this application track and calculate the load overhead of each interrupt request, thereby avoiding the coarse algorithm that can only calculate the load based on the number of interrupts in the past. This supports more accurate interrupt balancing, and the time overhead of soft interrupt processing triggered by hard interrupt processing is included in the corresponding interrupt processing duration, making the scheduling latency value determined based on the interrupt processing duration more accurate, so that subsequent interrupt balancing can be performed more accurately.

[0147] Furthermore, related technologies fail to consider scheduling latency caused by interrupt handling when selecting cores for tasks, resulting in excessive scheduling latency; or they use a uniform interrupt load judgment standard for all threads, causing background threads to select the same processor core as the designated thread, leading to unpredictable effects (such as lock holding preventing scheduling). This application's embodiment supports configuring scheduling latency requirements for designated threads and determines whether the scheduling latency requirement is greater than or equal to the processor core's scheduling latency value during core selection. Only when the requirement is met is the corresponding processor core selected, ensuring timely scheduling of the designated thread and reducing the probability of frame drops. Non-critical threads (such as background threads), since they have no latency requirements, can select processor cores with higher scheduling latency values, reducing interference with the operation of critical threads. Figure 6 The electronic device shown in the figure, the task selection process includes the following steps, such as Figure 9 As shown:

[0148] Step 901: The user layer configures a second latency threshold for a specified thread of the foreground application and sends third configuration information to the kernel layer.

[0149] Optionally, the user layer determines a specific thread of the foreground application and configures a maximum scheduling latency, i.e., a second latency threshold, for that specific thread. The user layer sends third configuration information to the kernel layer, which includes the thread identifier of the specified thread and the second latency threshold.

[0150] The thread identifier of the specified thread is used to uniquely identify the specified thread among multiple threads. The specified thread is a thread that has requirements for scheduling latency. Optionally, the specified thread includes the rendering thread and / or the process of inter-process communication mechanism. For example, the specified thread is the UI / Render thread, the Surfaceflinger thread, and the communication-related binder thread, etc. The embodiments of this application do not limit the type of the specified thread.

[0151] The second delay threshold is the upper limit of the scheduling delay value configured for the specified thread.

[0152] The second delay threshold can be dynamically adjusted based on the completion status of subsequent frame rendering. For example, if the absolute value of the difference between the actual end time of the previous frame rendering and the specified end time is greater than the second difference threshold, the second delay threshold is increased; if the absolute value of the difference between the actual end time of the previous frame rendering and the specified end time is less than or equal to the second difference threshold, the second delay threshold is decreased to ensure that threads can be scheduled faster. The second difference threshold can be a custom setting or a default setting. This application does not limit this.

[0153] Optionally, the user layer identifies a specified thread, obtains its thread identifier, configures a second latency threshold for the specified thread, and sends third configuration information to the kernel layer via a preset method. For example, the preset method is I / O device control (ioctl). The third configuration information might include "tid = 1200; lat_req = 200000", where the thread identifier of the specified thread is 1200, and the scheduling latency requirement is 200000ns, or 200us.

[0154] Step 902: The kernel layer determines the processor core that meets the preset core selection conditions as the target processor core based on the third configuration information. The preset core selection conditions include that the current scheduling latency value of the processor core is less than or equal to the second latency threshold.

[0155] After receiving the third configuration information from the user layer, the kernel layer checks the current state of the specified thread corresponding to the thread identifier. If the specified thread is currently executing, no action is taken. If the specified thread is not currently executing, the kernel layer attempts to wake it up. If the specified thread is not allowed to be woken up (e.g., waiting for a lock), the kernel layer modifies the second latency threshold of the scheduling latency requirement (e.g., decreasing the second latency threshold). If the specified thread is allowed to be woken up, the kernel selection process begins.

[0156] Optionally, in the core selection process, for one of the multiple processor cores, the kernel layer determines whether the processor core meets the preset core selection conditions. The preset core selection conditions include that the current scheduling latency of the processor core is less than a second latency threshold. If the processor core meets the preset core selection conditions, then the processor core is determined as the target processor core, and step 903 is executed; if the processor core does not meet the preset core selection conditions, then the next processor core is checked, and the step of determining whether the processor core meets the preset core selection conditions is executed again.

[0157] It should be noted that the current scheduling latency value of the processor core can be statistically analyzed by analogy with the current scheduling latency value of the target processor core described above, and will not be repeated here.

[0158] Optionally, the preset core selection criteria include the processor core's current scheduling latency being less than a second latency threshold and other core selection criteria. For example, other core selection criteria include the processor's priority being greater than a preset priority threshold, and / or the processor's attribute information matching the specified thread. This application does not limit this to specific criteria.

[0159] Step 903: The kernel layer adds the specified thread to the scheduling queue of the target processor core.

[0160] After the kernel layer adds the specified thread to the scheduling queue of the target processor core, it waits for scheduling execution. Since the scheduling latency of the specified thread is within a controllable range, the specified thread can be scheduled in a timely manner within the time required to meet the scheduling latency requirements.

[0161] In summary, the embodiments of this application support configuration of scheduling latency requirements at the task level, distinguishing between foreground and background threads and reducing the impact of background threads on specified foreground threads. When selecting a core for a task, the scheduling latency requirements of the task and the scheduling latency value of the processor core are considered. Only when the current scheduling latency value of the processor core is less than or equal to the second latency threshold of the task scheduling latency requirement can that processor core be selected as the target processor core, ensuring that critical threads can select processor cores with low scheduling latency values ​​and receive timely scheduling.

[0162] In an illustrative application scenario, such as Figure 10As shown, the "App Market" application A runs in the foreground on the phone. When a click signal is received from control 1001 in application A, five recommended applications are updated in batches. After the phone switches application A to the background, the "Magazine Hub" application is opened to display multiple magazine covers. Because application A needs to download upgrade packages over the network during batch updates, a large amount of network traffic is received / forwarded through the wireless network card. Since the network card reads and writes data from its memory by notifying the kernel layer through interrupt requests, a large number of network card interrupt requests are generated. Furthermore, due to the data packet processing involved, the interrupt handling of network packet transmission and reception often takes a long time (up to 10ms). If the UI / Render thread, Surfaceflinger thread, and other frame rendering threads select the processor core that is currently or will be handling a network card interrupt at this time, frame drops are very likely to occur, causing the user interface to stutter when browsing magazines in application B.

[0163] To address the aforementioned problems, the task selection method provided in this application includes the following steps: Figure 11 As shown: Step 1101, the Framework layer identifies the foreground application as "Magazine Hub" application B, and configures the second latency threshold of 500us for the UI / Render thread of application B as a critical scheduling latency requirement; Step 1102, the Framework layer sets the first latency threshold of 500us for processor core 0 and processor core 4 (4 small cores + 4 large cores architecture) to ensure that the task scheduling latency of at least one processor core is controllable for both small and large cores; Step 1103, after the Framework layer issues the first latency threshold, processor core 0 and processor core 4 decide whether to bind some interrupt requests sent to their respective processor cores to other processor cores based on the current scheduling latency value. After the interrupt requests exceeding the first latency threshold are moved out, the scheduling latency value of processor core 0 and processor core 4 can be guaranteed to be below 500us; Step 1104, when the mobile phone receives the swipe operation signal in application B, it triggers the frame drawing operation, and application B calls the UI / Render thread to draw the frame. In step 1105, after the UI / Render thread is awakened, the core selection process is carried out according to the second latency threshold required by the scheduling latency requirement. At this time, since other processor cores are processing network card interrupts and have a high load, processor core 0 and processor core 4 will most likely be selected. After adding the UI / Render thread to the scheduling queue of these two processor cores, since the scheduling latency value is less than 500us, it can be guaranteed that the UI / Render thread will be scheduled within 500us, thereby reducing the probability of frame drops and stuttering.

[0164] In an illustrative example, such as Figure 12As shown, in related technologies (assuming application B takes 16.7ms to draw one frame), due to the lack of control over scheduling latency, a specified thread may remain in a runnable state for an extended period, such as 3ms or 8ms, due to interrupt processing. Once the interrupt processing time exceeds 6ms, frame dropping is highly likely. However, the interrupt scheduling method provided in this application adjusts the scheduling latency of the specified thread to 500us, thereby ensuring that the scheduling latency of the specified thread remains within a controllable range and preventing frame dropping and stuttering issues caused by scheduling delays.

[0165] Please refer to Figure 13 This document illustrates a flowchart of an interrupt scheduling method provided in another exemplary embodiment of this application. The embodiments of this application illustrate the application of this interrupt scheduling method in an electronic device. The interrupt scheduling method includes:

[0166] Step 1301: Obtain the pre-configured first delay threshold, which is the maximum scheduling delay caused by interrupt handling configured for the first processor core.

[0167] Step 1302: Obtain the scheduling delay value of the first processor core. The scheduling delay value is used to indicate the current interrupt load of the first processor core.

[0168] Step 1303: If the scheduling delay value is greater than the first delay threshold, migrate and bind some of the current interrupt requests of the first processor core to the second processor core, which is different from the first processor core.

[0169] It should be noted that the relevant details of each step in this embodiment can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0170] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0171] Please refer to Figure 14 This diagram illustrates a block diagram of an interrupt scheduling apparatus provided in an exemplary embodiment of this application. The apparatus can be implemented through software, hardware, or a combination of both, becoming all or part of the electronic device described above. The apparatus may include: a first acquisition unit 1410, a second acquisition unit 1420, and a binding unit 1430.

[0172] The first acquisition unit 1410 is used to acquire a pre-configured first delay threshold, which is the maximum value of the scheduling delay caused by the interrupt handling configured for the first processor core.

[0173] The second acquisition unit 1420 is used to acquire the scheduling delay value of the first processor core, and the scheduling delay value is used to indicate the current interrupt load of the first processor core;

[0174] Binding unit 1430 is used to migrate and bind a portion of the current interrupt requests of the first processor core to the second processor core when the scheduling delay value is greater than the first delay threshold. The second processor core is different from the first processor core.

[0175] In one possible implementation, the scheduling latency of the first processor core after migration binding is less than or equal to a first latency threshold.

[0176] In another possible implementation, after migration binding, the absolute value of the difference between the scheduling latency values ​​of other processor cores is less than a preset first difference threshold, and the other processor cores are all processor cores other than the first processor core.

[0177] In another possible implementation, the device is used in an electronic device including a user layer, a kernel layer, and a hardware layer. The first acquisition unit 1410 is further used to send first configuration information to the kernel layer through the user layer. The first configuration information includes the processor core identifier of the first processor core and a first latency threshold. The kernel layer receives the first configuration information sent by the user layer.

[0178] The binding unit 1430 is also used to send second configuration information to the interrupt controller of the hardware layer through the kernel layer when the scheduling delay value is greater than the first delay threshold. The second configuration information includes the interrupt number to be migrated out in the first processor core and the processor core identifier of the second processor core. The interrupt controller migrates and binds at least one interrupt request corresponding to the interrupt number to the second processor core according to the second configuration information.

[0179] In another possible implementation, the device further includes a statistical unit; the statistical unit is used for:

[0180] After receiving an interrupt request, obtain the interrupt handling duration corresponding to the interrupt request. The interrupt handling duration includes the total duration of hardware interrupt handling and software interrupt handling.

[0181] Based on the interrupt handling duration of the interrupt request, a preset algorithm is used to determine the scheduling delay value corresponding to the interrupt request;

[0182] The updated scheduling delay value is obtained by summing the scheduling delay value corresponding to the interrupt request with the current scheduling delay value of the first processor core.

[0183] In another possible implementation, the device further includes: a core selection unit; the core selection unit is used for:

[0184] Obtain the pre-configured second delay threshold, which is the maximum scheduling delay caused by interrupt handling configured for the specified thread;

[0185] After a specified thread is awakened, the processor core that meets the preset core selection criteria is determined as the target processor core. The preset core selection criteria include that the current scheduling latency value of the processor core is less than or equal to the second latency threshold.

[0186] Add the specified thread to the scheduling queue of the target processor core.

[0187] In another possible implementation, the specified thread includes the foreground application's frame-drawing process and / or the process of the inter-process communication mechanism.

[0188] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0189] This application provides an electronic device, which includes: a processor; and a memory for storing processor-executable instructions; wherein, when the processor is configured to execute instructions, it implements the interrupt scheduling method executed by the electronic device in the above embodiments.

[0190] This application provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the interrupt scheduling method executed by the electronic device in the above embodiments.

[0191] This application provides a non-volatile computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the interrupt scheduling method executed by the electronic device in the above embodiments.

[0192] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), electrically programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital video disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing.

[0193] The computer-readable program instructions or code described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0194] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as "C" or similar languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing state information from computer-readable program instructions. These electronic circuits can execute computer-readable program instructions to implement various aspects of this application.

[0195] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0196] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0197] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0198] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.

[0199] It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, can be implemented using hardware (such as circuits or ASICs (Application Specific Integrated Circuits)) that performs the corresponding function or action, or using a combination of hardware and software, such as firmware.

[0200] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0201] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. An interrupt scheduling method, characterized in that, The method includes: Obtain a pre-configured first latency threshold, which is the maximum scheduling latency caused by interrupt handling configured for the first processor core; Obtain the scheduling delay value of the first processor core, the scheduling delay value being used to indicate the current interrupt load of the first processor core; When the scheduling delay value is greater than the first delay threshold, some interrupt requests of the first processor core are migrated and bound to the second processor core, which is different from the first processor core; The method further includes: Upon receiving an interrupt request, the interrupt processing duration corresponding to the interrupt request is obtained, and the interrupt processing duration includes the total duration of hardware interrupt processing and software interrupt processing. Based on the interrupt processing duration of the interrupt request, a preset algorithm is used to determine the scheduling delay value corresponding to the interrupt request; The scheduling delay value corresponding to the interrupt request is summed with the current scheduling delay value of the first processor core to obtain the updated scheduling delay value.

2. The method according to claim 1, characterized in that, After the migration binding, the scheduling latency of the first processor core is less than or equal to the first latency threshold.

3. The method according to claim 1, characterized in that, After the migration binding, the absolute value of the difference between the scheduling latency values ​​of other processor cores is less than a preset first difference threshold. The other processor cores are all processor cores other than the first processor core.

4. The method according to any one of claims 1 to 3, characterized in that, The method is used in an electronic device including a user layer, a kernel layer, and a hardware layer, wherein obtaining a pre-configured first latency threshold includes: The kernel layer receives first configuration information sent by the user layer, the first configuration information including the processor core identifier of the first processor core and the first latency threshold; When the scheduling delay value is greater than the first delay threshold, migrating and binding a portion of the current interrupt requests of the first processor core to the second processor core includes: When the scheduling delay value is greater than the first delay threshold, the kernel layer sends second configuration information to the interrupt controller of the hardware layer. The second configuration information includes the interrupt number to be migrated out in the first processor core and the processor core identifier of the second processor core. The second configuration information is used to instruct the interrupt controller to migrate and bind at least one interrupt request corresponding to the interrupt number to the second processor core.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Obtain the pre-configured second delay threshold, which is the maximum scheduling delay caused by interrupt handling configured for the specified thread; After the specified thread is awakened, the processor core that meets the preset core selection conditions is determined as the target processor core. The preset core selection conditions include that the current scheduling latency value of the processor core is less than or equal to the second latency threshold. Add the specified thread to the scheduling queue of the target processor core.

6. The method according to claim 5, characterized in that, The specified thread includes the foreground application's frame drawing process and / or the process of the inter-process communication mechanism.

7. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method of any one of claims 1-6 when executing the instructions.

8. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-6.

9. A computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, characterized in that, When the computer-readable code is run in an electronic device, the processor in the electronic device performs the method according to any one of claims 1-6.

Images