Scheduling method and electronic equipment

Abstract

The embodiment of the invention relates to the technical field of task scheduling, in particular to a scheduling method and electronic equipment, which can prolong the running time of a CPU occupied by a low-priority task in a scheduling period and solve the problem that a high-priority task is hungry or starved due to waiting for resource release. The method comprises the following steps: determining a current scene as a starvation scene; the starvation scene indicates that tasks in the queue waiting for CPU scheduling are in a starvation state; calculating first running time of the CPU occupied by the first task; the first task is a task in a queue, the priority level of the first task is a low priority, and the first running time is greater than the first reference time; wherein the priority level of the low priority is lower than or equal to a specified level; the first reference time is running time calculated according to the reference weight corresponding to the priority level of the first task.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of task scheduling, in particular to a scheduling method and an electronic device. BACKGROUND

[0002] In an operating system using a Linux kernel, for ordinary tasks with a priority of 100-139, a Completely Fair Scheduler (CFS) can be used for task scheduling, and the scheduling principle is to allocate CPU (Central Processing Unit) usage time according to the priority of the task. Different priorities correspond to different weights, and the usage time of the CPU is calculated and allocated according to the weights.

[0003] At present, the weight value corresponding to the highest priority and the weight value corresponding to the lowest priority differ greatly, for example, the weight corresponding to the highest priority is 88761, and the weight corresponding to the lowest priority is 15, with a ratio of 5917 times. In a high-load system scenario, the time slice obtained by a low-priority task is extremely short, and the low-priority task cannot be scheduled for a long time, so that the resources held by the low-priority task cannot be released, and the high-priority task can only be in an uninterrupted sleep state waiting for the low-priority task to release resources, and the high-priority task will therefore starve. SUMMARY

[0004] The embodiments of the present application provide a scheduling method and an electronic device, which improve the running time of a low-priority task in a scheduling period to solve the problem of starvation or death of a high-priority task caused by waiting for resource release.

[0005] In a first aspect, the embodiments of the present application provide a scheduling method, which can first determine that the current scenario is a starvation scenario; the starvation scenario indicates that a task in a queue waiting for CPU scheduling is in a starvation state; a first running time of a first task occupying the CPU is calculated; the first task is a task in the queue, and the priority level of the first task is a low priority, and the first running time is greater than a first reference time; wherein the low priority is a priority level lower than or equal to a specified level; and the first reference time is a running time calculated according to a reference weight corresponding to the priority level of the first task.

[0006] The reference weight is the weight corresponding to each priority recorded in the priority-weight mapping table Sche_prio_to_weight adopted in the existing CFS scheduling mechanism based on the Linux kernel. The first reference time is the time calculated according to the reference weight corresponding to the priority level of the first task.

[0007] By the above method, the low-priority task can be given more time slices, and thus can be executed faster to release the lock or other synchronization resources held by the low-priority task, and the starvation or death problem of other tasks caused by waiting for the synchronization resources can be reduced.

[0008] In a possible implementation, the method can detect that the current task scheduling scenario is a starvation scenario.

[0009] In a possible implementation, the detection that the current task scheduling scenario is a starvation scenario can be performed in a periodically generated clock interrupt.

[0010] The detection of the starvation scenario can distinguish the starvation scenario from a normal scenario, so as to avoid the influence of the change of the weights of the tasks of different priorities on the scheduling mechanism in the normal scenario, and thus the CFS scheduling can be normally performed according to the existing mechanism when the starvation phenomenon does not occur.

[0011] In a possible implementation, the detection that the current task scheduling scenario is a starvation scenario can be that it is detected that the number of tasks in the queue is greater than or equal to a first threshold value, and / or it is detected that the duration for which at least one task waits for CPU scheduling in the queue is greater than or equal to a second threshold value, and it is determined that the current task scheduling scenario is a starvation scenario.

[0012] In a possible implementation, the calculation of the first running time of the first task on the CPU can be that the first weight mapping table is selected from the first weight mapping table and a second weight mapping table, and the first running time of the first task on the CPU is calculated. The first weight mapping table is used to record the first weight corresponding to each priority in the starvation scenario; the second weight mapping table is used to record the reference weight corresponding to each priority in the non-starvation scenario; and the first weight corresponding to the first task is greater than the reference weight corresponding to the first task.

[0013] In a possible implementation, the weight corresponding to the low priority in the first weight mapping table is greater than or equal to the weight corresponding to the same priority in the second weight mapping table; and the weight corresponding to the high priority in the first weight mapping table is less than or equal to the weight corresponding to the same priority in the second weight mapping table; and the high priority is a priority level higher than or equal to a specified level.

[0014] In a possible implementation, after it is determined that the current scenario is a starvation scenario, the second running time of a second task on the CPU can also be calculated; the second task is another task in the queue, the second task is a high-priority task, and the second running time is less than a second reference time; and the second reference time is a running time calculated according to the reference weight corresponding to the priority level of the second task.

[0015] In a possible implementation, the first gap corresponding to the first weight mapping table is smaller than the second gap corresponding to the second weight mapping table; wherein the first gap is a gap between the minimum weight and the maximum weight in the first weight mapping table; and the second gap is a gap between the minimum weight and the maximum weight in the second weight mapping table.

[0016] The gap can be a ratio or a difference or other calculation mode representing the distance between weights, for example, the first gap is a ratio of the maximum weight to the minimum weight in the first weight mapping table, or a difference between the maximum weight and the minimum weight, etc. The second gap is a ratio of the maximum weight to the minimum weight in the second weight mapping table, or a difference between the maximum weight and the minimum weight, etc.

[0017] In a second aspect, the embodiments of the present application further provide an electronic device, comprising: a processor configured to execute computer programs or instructions in a memory to implement the method according to any one of the preceding method embodiments.

[0018] In a third aspect, the embodiments of the present application further provide a computer readable storage medium, comprising a stored program, wherein the program is executed by a processor to implement the method according to any one of the preceding method embodiments.

[0019] In a fourth aspect, the embodiments of the present application further provide a chip system, comprising: a communication interface configured to input and / or output data; and a processor configured to execute computer executable programs, so that a device installed with the chip system executes the method according to any one of the preceding method embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 A software architecture diagram of an electronic device in the scheduling method provided by the embodiments of the present application is provided.

[0021] Figure 2 A flowchart of one specific embodiment of the scheduling method provided by the embodiments of the present application is provided.

[0022] Figure 3 A flowchart of the scheduling method provided by the embodiments of the present application is provided. DETAILED DESCRIPTION

[0023] In order to better understand the technical solutions of the present application, the embodiments of the present application will be described in detail below with reference to the drawings.

[0024] It should be clear that the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0025] The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the specification. As used in the embodiments of the present application and the accompanying claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0026] In the Linux kernel-based operating system, the priority of a task is divided into real-time priority and normal priority. The real-time priority is used for real-time applications, such as hard real-time tasks and real-time control systems, and the normal priority is used for non-real-time applications. Tasks with dynamic priorities of 0-99 are real-time tasks, and tasks with dynamic priorities of 100-139 are normal tasks.

[0027] For normal tasks with priorities of 100-139, a CFS scheduler can be used for scheduling. CFS is a task scheduling mechanism based on the Linux kernel. The principle is to allocate CPU usage time according to task priority, and tasks with higher priority occupy running time for a longer time. In order to quantify the impact of priority on task running time, the CFS scheduler introduces the concept of weight. Each task is allocated CPU time according to the weight ratio on the CPU, and the time slice corresponding to each task is determined. Time slice, i.e. the time allocated to each task by the CPU, each task is allocated a time period, called time slice.

[0028] The CFS scheduler maps different priorities to different weights. When a task wakes up, CFS determines the weight corresponding to the priority level of the task according to the mapping relationship between priority and weight, calculates the CPU usage time of the task in a scheduling period according to the weight, and determines the time slice corresponding to the task before the task can be scheduled and run by the CPU.

[0029] The formula for calculating CPU running time according to weight is as follows:

[0030] CPU running time = scheduling period * task weight / sum of all task weights.

[0031] For example, taking task A and task B as an example, in the current scheduling scenario, the weight of task A is 1024 and the weight of task B is 820, then the CPU running time ratio of the two tasks is as follows:

[0032] Task A: 1024 / (1024+820) = 55.5%;

[0033] Task B: 820 / (1024+820) = 44.5%;

[0034] If a scheduling period is T, the CPU running time of the two tasks is:

[0035] Task A: T*1024 / (1024+820)=T*55.5%;

[0036] Task B: T*820 / (1024+820)=T*44.5%.

[0037] In CFS, the priority of a normal task can be marked by a nice value, and the range of the nice value is: [-20-19], the higher the nice value, the lower the priority; the lower the nice value, the higher the priority.

[0038] The priority weight mapping table records different weight values mapped based on different nice values, for example, in the Linux kernel, the priority weight mapping table sched_prio_to_weight

[40] referred to by CFS in allocating time slices is as follows:

[0039]

[0040] Among them, "88761, 71755, 56483, 46273, 36291" correspond to nice values -20, -19, -18, -17, -16;

[0041] "36, 29, 23, 18, 15" correspond to nice values 15, 16, 17, 18, 19;

[0042] "1024, 820, 655, 526, 423" correspond to nice values 0, 1, 2, 3, 4;

[0043] The other rows are similar. For ease of description, the priority weight mapping table sched_prio_to_weight

[40] is referred to as the second weight mapping table below. The weight corresponding to each priority in sched_prio_to_weight

[40] is referred to as the reference weight.

[0044] As can be seen, the highest priority (nice value -20) corresponds to a weight of 88761, and the lowest priority (nic value 19) corresponds to a weight of 15, and the extreme values of the weights differ by as much as 5917 times, which results in the time slice obtained by a high-priority task being much longer than that obtained by a low-priority task.

[0045] Due to the large priority mapping weight difference, in a high load scenario of the system, a low priority task often obtains a very short time slice. When the low priority task holds a lock or other synchronization resource, a high priority task can only be in an uninterrupted sleep state to wait for the low priority task to release the resource. However, the low priority task is allocated a time slice that is too short, which can cause the low priority task to be unable to be scheduled for a long time, so that the lock resource cannot be released, and the high priority task can starve or starve to death.

[0046] The starvation or death of the high priority task can cause a hung task panic of the kernel, an application not response (ANR), a system virtual machine restart, and other stability problems.

[0047] In addition, due to multiple lock waiting or the high priority task being in an RCU (Read-Copy Update) synchronization stage, the root cause of the problem is easily confused and difficult to analyze clearly, which greatly increases the difficulty of system maintenance.

[0048] In other operating systems, such as a windows system or an IOS system, there are some improvement schemes for task starvation, but there is currently a lack of improvement schemes for a Linux kernel operating system.

[0049] In view of this, an embodiment of the present application provides a scheduling method for dynamically allocating weights of a CFS scheduler. The method increases a CPU time slice of a low priority task in a high load scenario, improves the time of the low priority task using the CPU, and enables the low priority task holding a synchronization resource to execute as soon as possible to release the synchronization resource held by the low priority task. The method solves the problems of starvation and death of other tasks caused by waiting for the synchronization resource to be released, and further avoids some stability problems caused by task starvation and death.

[0050] The scheduling method provided in the embodiment of the present application can be applied to a CFS scheduling scenario based on a Linux kernel. The method can run based on various operating systems (OSs) with a Linux kernel, such as an Android, a Harmony, and the like. Further, the scheduling method provided in the embodiment of the present application can be applied to an electronic device installed with an operating system with a Linux kernel.

[0051] The electronic device can be a mobile phone, a tablet computer, a handheld computer, a desktop computer, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), and a smart television, a smart camera and the like smart home device, a smart bracelet, a smart watch, smart glasses and the like wearable device, an augmented reality (AR), a virtual reality (VR), a mixed reality (MR) and the like extended reality (XR) device, a vehicle-mounted device or a smart city device, and the specific type of the electronic device is not specially limited in the embodiments of the present application.

[0052] Taking the mobile phone as an example, the electronic device 100 can adopt the following hardware architecture: the electronic device 100 can include a processor 110, an external memory interface 120, an internal memory 121, and a universal serial bus (USB) interface 130.

[0053] The processor 110 can be a homogeneous architecture processor or a heterogeneous architecture processor, and the processor can be a multi-core processor or a single-core processor. In the following description, the CPU can refer to a multi-core CPU or a single-core CPU, or one core in a multi-core CPU.

[0054] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices or integrated in one or more processors. The controller can generate operation control signals according to instruction operation codes and timing signals to complete the control of fetching and executing instructions.

[0055] The processor 110 can also include a memory for storing instructions and data. In one embodiment, the memory in the processor 110 is a cache memory. The memory can hold instructions or data that the processor 110 has just used or is using repeatedly. If the processor 110 needs to use the instructions or data again, it can call them directly from the memory. This avoids repeated access and reduces the waiting time of the processor 110, thus improving the efficiency of the system.

[0056] In one embodiment, the processor 110 can include one or more interfaces. The interfaces can include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0057] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to realize data storage functions. For example, music, video, and other files are saved in the external memory card.

[0058] The internal memory 121 can be used to store computer executable program codes including instructions. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required for a function (such as a sound play function, an image play function, etc.), and the like. The data storage area can store data (such as audio data, a phone book, etc.) created during use of the electronic device 100, and the like. In addition, the internal memory 121 can include a high-speed random access memory, and can further include a non-volatile memory such as at least one of a magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like. The processor 110 performs various function applications and data processing of the electronic device 100 by executing instructions stored in the internal memory 121 and / or instructions stored in a memory disposed in the processor.

[0059] It should be understood that the above description is only one example of the electronic device 100, and the electronic device 100 can have more or less components than those described in the above description, can combine two or more components, or can have a different component configuration. The above various components can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

[0060] The software system of the electronic device 100 is described below.

[0061] The software system of the electronic device 100 can employ a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. For example, the software system of the layered architecture can be an Android system, a harmony operating system, or other software systems. Embodiments of the present application take the Android system of the layered architecture as an example to illustrate the software structure of the electronic device 100.

[0062] Figure 1 An example of a software architecture diagram of the electronic device 100 is shown.

[0063] The layered architecture divides software into several layers, each of which has a clear role and division of labor. Layers communicate with each other through software interfaces. In an embodiment, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Android runtime and system library, and a Linux kernel layer.

[0064] The application layer can include a series of application packages.

[0065] As Figure 1As shown, the application package may include applications such as camera, calendar, music, gallery, SMS, call, navigation, translation, and browser. The translation function in this application can be a standalone application or a functional module integrated into other applications; this application does not limit its scope. The applications in this application can also be replaced with other forms of software such as mini-programs or atomic services.

[0066] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0067] like Figure 1 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0068] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0069] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0070] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0071] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0072] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0073] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the system's top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting alert sounds, vibrating electronic devices, and flashing indicator lights.

[0074] The Android Runtime includes a core library and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0075] The core library contains two parts: one part is the function function that the java language needs to call, and the other part is the core library of Android.

[0076] The application layer and the application framework layer run in the virtual machine. The virtual machine executes the java file of the application layer and the application framework layer into a binary file. The virtual machine is used to perform the management of the object life cycle, the management of the stack, the management of the thread, the management of the security and the exception, and the garbage collection and the like.

[0077] The system library can include a plurality of functional modules. For example: a surface manager, media libraries, a three-dimensional graphics processing library (for example: OpenGL ES), a 2D graphics engine (for example: SGL) and the like.

[0078] The surface manager is used for managing the display subsystem, and provides a plurality of applications with the fusion of 2D and 3D layers.

[0079] The media library supports a plurality of commonly used audio, video format playback and recording, and static image files and the like. The media library can support a plurality of audio and video coding formats, for example: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG and the like.

[0080] The three-dimensional graphics processing library is used for realizing three-dimensional graphics drawing, image rendering, synthesis, and layer processing and the like.

[0081] The 2D graphics engine is a drawing engine for 2D drawing.

[0082] The Linux kernel layer is a layer between hardware and software. The Linux kernel layer at least contains a display driver, a camera driver, an audio driver, and a sensor driver.

[0083] In the embodiment of the present application, the Linux kernel layer includes a CFS scheduler. The scheduling method proposed in the embodiment of the present application increases the detection of the starvation scene on the basis of the CFS scheduler. If it is a starvation scene, the weight recorded in a new priority-weight mapping table (referred to as a first weight mapping table) designed for the starvation scene is selected to calculate the running time corresponding to each task. The new weight mapping table designed for the starvation scene should at least make the calculated low-priority task occupy a longer time slice of the CPU within a scheduling period.

[0084] It should be noted that in the embodiments of the present application, the task can be a thread, and in other embodiments, the task can also be a process, and the process includes at least one thread. The thread is the most basic unit of CPU scheduling.

[0085] A specific embodiment is listed below.

[0086] In the present embodiment, the current CPU scheduling state is analyzed in the CPU clock interrupt flow, and the current CPU task number exceeds 20 or there is a task in the queue in the ready state (Runnable) for more than 500 ms, which is determined as a starvation scenario; when the task is queued, first, according to the scene detection result in the interrupt flow, if it is a starvation scenario, the starve_prio_to_weight weight table in the starvation scenario is used to calculate the time slice, and if it is not determined as a starvation scenario, the sched_prio_to_weight weight table in the normal scenario is used to calculate the time slice. In the starve_prio_to_weight weight table, the weight of the high priority task is reduced, and the weight of the low priority task is increased, so that the time slice of the low priority task is increased, and the starvation or death of other tasks is avoided.

[0087] Firstly, it is necessary to determine whether the current scheduling scenario is a starvation scenario. The starvation scenario can be understood as that in the queue waiting for the current CPU scheduling, at least one task has a starvation phenomenon or a death phenomenon. The new priority weight mapping table (the first weight mapping table) is used in the starvation scenario to alleviate the task starvation state, solve the task death problem, and does not affect the time slice allocation in the normal scenario.

[0088] Specifically, in the present embodiment, whether the current CPU task number exceeds 20 or waits for more than 500 ms in the queue can be detected in the cpu clock interrupt flow to identify the starvation scenario in advance. As shown in Figure 2 The current scenario can be detected whether it is a starvation scenario, which can include the following steps:

[0089] S101, the CPU generates a clock interrupt;

[0090] S102, calling schedule_tick;

[0091] Taking task C as an example, when task C is scheduled to run on the CPU, that is, task C occupies the CPU, the CPU will periodically generate a clock interrupt, and in the interrupt processing flow, the schedule_tick flow is called to calculate whether the time slice of the current CPU task (task C) is used up. If the time slice is exhausted, the current task will be scheduled in time, and the next executed task is selected.

[0092] In this embodiment, the starvation detection module can be added in the schedule_tick flow by using the interrupt mechanism, so that the starvation detection is performed when the schedule_tick flow is called, and thus the existing interrupt mechanism can be compatible and the modification range of the CFS scheduling mechanism can be reduced. The specific manner of starvation detection can refer to S103 to S105.

[0093] S103, it is judged whether the number of tasks in the current queue exceeds the first threshold value. Yes, enter S105, otherwise, return to continue to judge.

[0094] For example, in this embodiment, the first threshold value can be 20. In other embodiments, the first threshold value can be other numerical values, for example, the first threshold value can be 19 or 21, etc. Generally, the value range of the first threshold value is [15, 35].

[0095] S104, it is judged whether there is a task in the current queue whose waiting duration exceeds the second threshold value. Yes, enter S105, otherwise, return to continue to judge.

[0096] For example, the second threshold value can be 500ms. In other embodiments, the second threshold value can be other numerical values, for example, the second threshold value can be 450ms or 550ms, etc. Generally, the value range of the second threshold value is [450ms, 550ms].

[0097] The waiting duration can be understood as the duration of the task waiting to be scheduled by the CPU or said to be waiting to be executed by the CPU after entering the queue. For example, the waiting duration can be the duration of the task in the ready state after changing from other states to the ready state.

[0098] S105, determine that the current scenario is a starvation scenario.

[0099] For example, a global variable can be set to represent whether the current scenario is a starvation scenario. If it is determined to be a starvation scenario, the value of the global variable is updated, and if it is not a starvation scenario, the value of the global variable is not updated. For example, a global variable α is set, α = 1 represents a starvation scenario, and α = 0 represents a non-starvation scenario, or said to represent a normal scenario.

[0100] It should be noted that the detection logic shown in the embodiment is that the number of tasks in the queue waiting for CPU scheduling currently exceeds the first threshold value or the waiting duration of the tasks in the queue exceeds the second threshold value, and one of the two judgment conditions is met to determine that the current scene is a starvation scene. In other embodiments, the current scene can be determined as a starvation scene only when the number of tasks in the queue exceeds the third threshold value and the waiting duration of the tasks in the queue exceeds the fourth threshold value, that is, both of the two judgment conditions are met. The third threshold value can be equal to the first threshold value, or can be different from the first threshold value. The fourth threshold value can be equal to the second threshold value, or can be different from the second threshold value.

[0101] In the scheduling method proposed in the embodiments of the present application, after it is determined whether the current scene is a starvation scene, time slices can be allocated to tasks of different priorities according to the flow as shown in Figure 2

[0102] S201, the task C becomes a ready state and is added to the queue waiting for CPU scheduling.

[0103] In the embodiment, the task can be a thread, and the task C can be a thread C in particular. In other embodiments, the task can be a process.

[0104] The state of a thread or a process includes a new state (New), a ready state (Runnable), a running state (Running), a blocked state (Blocked), and a dead state (Dead). Among them, the ready state (Runnable) is that after the thread object is created and the start() method is called, the thread in this state is located in a runnable thread pool and waits to be selected by a thread scheduling program to obtain the use right of CPU, but has not started running. The runnable thread pool is also a queue waiting for CPU scheduling.

[0105] The waiting duration of the task C in the queue can be the duration of the task C in the ready state (ready state for short) after the task C changes from the new state or other states to the ready state. The task C is in the ready state, which means that the task C is waiting to be scheduled by the CPU, that is, the waiting duration.

[0106] S202, it is determined whether the current scene is a starvation scene.

[0107] If yes, the starve_prio_to_weight (second weight mapping table) is selected; if no, the Sche_prio_to_weight (first weight mapping table) is selected.

[0108] ​Wherein, the starve_prio_to_weight is a new weight table set for the starvation scenario, and the Sche_prio_to_weight is a commonly used priority-weight mapping table in the original or current CFS scheduling mechanism.

[0109] Compared with the Sche_prio_to_weight, the weight of the low-priority task is increased, and / or the weight of the high-priority task is reduced, so as to improve the running time of the low-priority task, and thus solve the problem of task starvation or death.

[0110] In the starvation scenario, the priority-weight mapping table adopts the design idea of peak filling valley, which reduces the weight gap. The peak filling valley means reducing the high-priority weight and increasing the low-priority weight.

[0111] Exemplarily, for the starvation scenario, the new priority-weight mapping table (starve_prio_to_weight, i.e., the first weight mapping table) can be as follows:

[0112]

[0113] As can be seen, the mapping table reduces the weight corresponding to the high priority and increases the weight corresponding to the low priority, so as to achieve the effect of peak filling valley. Through this processing, the weight proportion of the low-priority task in the starvation scenario can be improved.

[0114] In this embodiment, when the starve_prio_to_weight is obtained based on the Sche_prio_to_weight, the peak clipping and valley filling principle is embodied as follows:

[0115] The weight corresponding to the nice value of 0 (dynamic priority of 120) is 1024, and the row "1024, 820, 655, 526, 423" where the weight 1024 is located remains unchanged. Taking the weight 1024 as the reference, the priority corresponding to the weight 1024 (the nice value of 0) is taken as the specified priority. The priorities lower than the specified priority are defined as low priorities, and the priorities higher than the specified priority are defined as high priorities.

[0116] For the low priority, 1024 is divided by an integer N, for example, N=4 in this embodiment, 1024 / 4=256, and all the weights less than 256 in the low priority are increased to 256.

[0117] For the high priority, 1024 is multiplied by an integer N, for example, N=4 in this embodiment, 1024*4=4096, and all the weights greater than 4096 in the high priority are reduced to 4096.

[0118] In other embodiments, N can take other values, for example, N = 8, 1024 * 8 = 8192, 1024 / 8 = 128, and the resulting starve_prio_to_weight is as follows:

[0119]

[0120] It can be seen that by changing the value of N, other specific examples of starve_prio_to_weight can be obtained, and this specification does not list them one by one.

[0121] S203, calculate the time slice.

[0122] If starve_prio_to_weight is selected, the time slice is calculated according to the weight corresponding to each priority recorded in starve_prio_to_weight, and if Sche_prio_to_weight is selected, the time slice is calculated according to the weight corresponding to each priority recorded in Sche_prio_to_weight.

[0123] In the above table starve_prio_to_weight, the weight value of the low-priority task is generally improved, for example, for the priority level of the lowest priority (nice value is 19), the weight value is increased from 15 to 256. And the weight value corresponding to the high priority is generally reduced. For example, the weight value of the highest priority is reduced from 88761 to 4096.

[0124] Thus, in this embodiment, a new priority weight mapping table is designed for the starvation scenario, the peak is filled and the valley is flattened, the weight corresponding to the low priority is increased, the weight corresponding to the high priority is reduced, the weight difference is controlled in the interval (256, 4096), and the ratio between the maximum weight value and the minimum weight is reduced to 16 times.

[0125] For example, assuming that the queue waiting for CPU scheduling currently includes 4 tasks with dynamic priority (prio) of 100, 20 tasks with dynamic priority (prio) of 120, and 1 task with dynamic priority (prio) of 139, the proportion of the time slice corresponding to the task with priority 139 in different scenarios is:

[0126] Normal scenario: 15 / (88761 * 4 + 1024 * 20 + 15) = 0.00399%;

[0127] Starvation scenario: 256 / (4096 * 4 + 1024 * 20 + 256) = 0.69%;

[0128] The weight proportion of the low-priority task in the starvation scenario is increased by 172 times compared with the normal scenario.

[0129] The weight ratio of the low priority is increased, and according to the algorithm mechanism of the CFS scheduling, the running time of the low priority task is prolonged, the low priority task that grasps the lock synchronization resource can be executed faster, so as to release the lock synchronization resource grasped by the low priority task, and the high priority task can grasp the lock synchronization resource earlier, the starvation or death phenomenon is reduced, and the stability problem caused by the task death in the high load scene is avoided to a certain extent.

[0130] S204, waiting for CPU scheduling.

[0131] According to the above description, as shown in Figure 3 The scheduling method proposed in the embodiments of the application can be summarized as follows:

[0132] S301: determining that the current scene is a starvation scene.

[0133] One of the ways to determine that the current scene is a starvation scene is as described in the above Figure 2 embodiment, a starvation scene detection can be added in the CPU interrupt flow, a variable for indicating whether the scene state is a starvation scene is assigned a value based on the detection result, and then when a new task is added to the queue, the value of the variable is read. If the value of the variable indicates that the current scene is a starvation scene, it is determined that the current scene is a starvation scene.

[0134] It should be noted that the timing of triggering the detection can be triggering the detection flow once every periodic interruption generated by the CPU, or triggering the detection flow once every several interruption flows, for example, triggering the starvation scene detection flow once every 2 interruptions or every 3 interruptions. Moreover, when a new task is added to the queue, the value of the variable can be read once every time a new task is added to determine whether the scene is a starvation state, or the value of the variable can be read once every time a plurality of new tasks are added to the queue, for example, the value of the variable for indicating whether the scene is a starvation state is read every time 2 or 3 new tasks are added.

[0135] In other embodiments, determining that the current scene is a starvation scene can also be performed in other ways, for example, the starvation scene detection can not be added in the interruption flow in advance, but the detection of whether the current scene is a starvation scene can be triggered every time a new task or a plurality of tasks are added to the queue. The current scene is determined to be a starvation scene according to the real-time detection result. Wherein, the new task added to the queue can be understood as the new task being changed from other states to the ready state to wait for CPU scheduling.

[0136] According to the above description, the current task scheduling scenario can be periodically detected as a starvation scenario, for example, in a periodically generated clock interrupt, the current task scheduling scenario is detected as a starvation scenario; or, each time one or more new tasks are added to the queue, a starvation scenario detection is triggered. The specific detection method can be to detect that the number of tasks in the queue is greater than or equal to a first threshold, and / or, at least one task in the queue waits for CPU scheduling for a time greater than or equal to a second threshold, to determine that the current task scheduling scenario is a starvation scenario.

[0137] In S302, a first running time of the first task occupying the CPU is calculated.

[0138] The first task is one of the tasks in the queue waiting for CPU scheduling.

[0139] In some embodiments, calculating the first running time of the first task occupying the CPU can be selecting the first weight mapping table from the first weight mapping table and the second weight mapping table, and calculating the first running time of the first task occupying the CPU.

[0140] The first weight mapping table (for example, starve_prio_to_weight) is used to record the first weight corresponding to each priority in the starvation scenario; and the second weight mapping table is used to record the reference weight corresponding to each priority in the non-starvation scenario (i.e. normal scenario or ordinary scenario).

[0141] Calculating the first running time of the first task occupying the CPU can be, after the first task is added to the queue, according to the detection result of the starvation scenario, if the current is a starvation scenario, according to the weight value corresponding to the priority of each task in the current queue recorded in the first weight mapping table, the weight proportion of the first task is calculated, and then the running time corresponding to the first task is obtained.

[0142] According to the description in the above embodiments, it can be known that, for ease of description, the running time corresponding to the first task calculated by using the original Sche_prio_to_weight table is defined as the first reference time, then if the priority level of the first task is a low priority, the first weight corresponding to the first task is greater than the reference weight corresponding to the first task, and then the first running time corresponding to the first task is greater than the first reference time. The first reference time is the running time calculated by the reference weight corresponding to the priority level of the first task. The weight corresponding to each priority in the original weight mapping table before the weight value is adjusted is the reference weight. For example, the weight recorded in Sche_prio_to_weight is the reference weight.

[0143] In the embodiments of the present application, the low priority refers to the priority level being lower than or equal to a specified level, and the high priority refers to the priority level being higher than or equal to the specified level. For example, the priority with a nice value of 0 is the specified level, the priority level lower than the specified level is the low priority, and the priority level higher than the specified level is the high priority.

[0144] If the task newly added to the queue is a high-priority task, for example, the second task is a high-priority task added to the queue, after it is determined that the current scenario is the starvation scenario, the second running time of the second task occupying the CPU can be calculated, and the calculated second running time is less than the second reference time, that is, the running time calculated based on the reference weight corresponding to the priority level of the second task.

[0145] Specifically, the above Figure 2 The manner of obtaining the first weight mapping table based on the second weight mapping table mentioned in the corresponding embodiments is only an example. In fact, based on the second weight mapping table (for example, Sche_prio_to_weight), the first weight mapping table can be obtained in multiple manners based on the peak clipping and valley filling principle. For example, the peak clipping and valley filling principle can be embodied as follows:

[0146] The weight corresponding to the low priority in the first weight mapping table is greater than or equal to the weight corresponding to the same level in the second weight mapping table, and the weight corresponding to the high priority in the first weight mapping table is less than or equal to the weight corresponding to the same level in the second weight mapping table. The first weight mapping table satisfying this rule can have multiple instances, for example:

[0147]

[0148] For another example:

[0149]

[0150] In other embodiments, the peak clipping and valley filling principle can also be embodied as follows:

[0151] The first gap corresponding to the first weight mapping table is less than the second gap corresponding to the second weight mapping table. The first gap is the gap between the minimum weight and the maximum weight in the first weight mapping table, and the second gap is the gap between the minimum weight and the maximum weight in the second weight mapping table. The first weight mapping table satisfying this rule can have multiple instances, for example:

[0152]

[0153] For another example,

[0154]

[0155] Therefore, the general principle of obtaining the first weight mapping table (e.g., starve_prio_to_weight) based on the second weight mapping table (e.g., Sche_prio_to_weight) is that, in the first weight mapping table, the weight of a low priority is greater than or equal to the weight corresponding to the same priority level in the second weight mapping table; and in the first weight mapping table, the weight of a high priority is less than or equal to the weight corresponding to the same priority level in the second weight mapping table. For a specified priority (the nice value is 0), the weight can remain unchanged at 1024, or can be adjusted appropriately, for example, to 820 or 1277, etc.

[0156] According to the above description of the embodiments of the present application, a large number of specific examples of the first weight mapping table dedicated to the starvation scenario can be obtained, and the present specification will not list them one by one.

[0157] In summary, the scheduling method proposed in the embodiments of the present application is aimed at the task starvation or death scenario that can occur during CPU scheduling, and adopts a method of dynamically assigning weights according to the scenario detection result, that is, dynamically selecting the weight table suitable for the current scenario from the first weight mapping table and the second weight mapping table, using the new first weight mapping table designed for the starvation scenario in the starvation scenario, and improving the weight corresponding to the low priority task to solve the problem of task starvation or death.

[0158] The embodiments of the present application also provide an electronic device, which comprises a processor configured to execute computer programs or instructions in a memory to implement the method according to any of the above embodiments.

[0159] Exemplarily, the processor can include one or more processing units, for example: the processor includes a neural-network processing unit (NPU), and can also include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a digital signal processor (DSP), a baseband processor, etc. Different processing units can be independent devices, or can be integrated in one or more processors. The controller can generate operation control signals according to instruction operation codes and timing signals to complete the control of fetching and executing instructions.

[0160] The memory can be configured to store computer-executable program codes including instructions. The internal memory can include a program storage area and a data storage area. The program storage area can store an operating system, application programs required by at least one function, and the like. The data storage area can store data (such as input data, output data) created during use of the electronic device, and the like. In addition, the internal memory can include a high-speed random access memory, and can further include a nonvolatile memory such as at least one of a magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like. The processor executes various function applications and data processing of the electronic device by running the instructions stored in the internal memory and / or the instructions stored in the memory disposed in the processor.

[0161] It can be understood that the structure shown in the embodiments of the present application is only an example and does not constitute a limitation on the electronic device. The electronic device in the embodiments of the present application can include more or fewer components than those shown, or combine some components, or split some components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0162] The embodiments of the present application also provide a computer-readable storage medium including a stored program, wherein the program is executed by a processor to implement the method in any of the above embodiments.

[0163] The embodiments of the present application also provide a computer program product including a program, which, when executed by an electronic device, causes the electronic device to implement the method in any of the above embodiments.

[0164] The embodiments of the present application also provide a chip system including: a communication interface configured to input and / or output data; and a processor configured to execute computer-executable programs, so that the device installed with the chip system implements the method in any of the above embodiments.

[0165] The computer readable storage medium can be implemented using any appropriate media including, but not limited to, non-volatile media, volatile media, or any suitable combination thereof. Non-volatile media includes, for example, optical or magnetic disks, among others. Volatile media includes computer system memory such as RAM, among others. The computer readable storage medium can also be any appropriate combination of non-volatile media and volatile media.

[0166] The computer readable signal medium can include a propagated data signal with computer readable program code embodied therein. The propagated data signal can take any suitable form including, but not limited to, radio frequency (RF) signals, infrared signals, optical signals, or any suitable combination thereof. The computer readable signal medium can be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport program code.

[0167] Program code embodied on a computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0168] In the description of the specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the person skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.

[0169] Furthermore, the terms "first", "second", etc. are used herein for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly pointing to the number of technical features indicated. Thus, features defined with "first", "second" etc. can explicitly or implicitly include at least one of such features. In the description of the present application, the meaning of "plurality" is at least two, for example two, three, etc., unless explicitly and specifically defined otherwise.

[0170] Any process or method descriptions or blocks in flow charts described herein and elsewhere can be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. The alternate implementations can also perform functions in a substantially simultaneous manner or in reverse order according to the functions involved, as will be understood by those skilled in the art. Accordingly, embodiments of the present application should not be construed as limited to any specific order or arrangement of processes or steps, except as specifically defined by patent claims and for those embodiments specifically recited as "order dependent."

Claims

1. A scheduling method, characterized by, The method comprises: determining that the current scenario is a starvation scenario; the starvation scenario indicates that a task in a queue waiting for CPU scheduling is in a starvation state; calculating a first running time of a first task occupying the CPU; the first task is one of the tasks in the queue, the priority level of the first task is a low priority, and the first running time is greater than a first reference time; wherein the low priority is a priority level lower than or equal to a specified level; and the first reference time is a running time calculated according to a reference weight corresponding to the priority level of the first task.

2. The method of claim 1, wherein, The method further comprises: detecting that the current scenario is a starvation scenario.

3. The method of claim 2, wherein, detecting that the current scenario is a starvation scenario, comprising: detecting that the current scenario is a starvation scenario in a periodically generated clock interrupt.

4. The method of claim 2 or 3, wherein detecting that the current scenario is a starvation scenario, comprising: detecting that the number of tasks in the queue is greater than or equal to a first threshold value, and / or detecting that the duration of at least one task waiting for CPU scheduling in the queue is greater than or equal to a second threshold value, to determine that the current scenario is a starvation scenario.

5. The method of any one of claims 1-4, wherein calculating a first running time of a first task occupying the CPU, comprising: selecting a first weight mapping table from the first weight mapping table and the second weight mapping table to calculate the first running time of the first task occupying the CPU; the first weight mapping table is used to record the first weight corresponding to each priority level in the starvation scenario; the second weight mapping table is used to record the reference weight corresponding to each priority level in the non-starvation scenario; the first weight corresponding to the first task is greater than the reference weight corresponding to the first task.

6. The method of claim 5, wherein the weight corresponding to the low priority in the first weight mapping table is greater than or equal to the weight corresponding to the same level in the second weight mapping table; the weight corresponding to the high priority in the first weight mapping table is less than or equal to the weight corresponding to the same level in the second weight mapping table; the high priority is a priority level higher than or equal to a specified level.

7. The method of any one of claims 1-6, wherein after determining that the current scenario is a starvation scenario, the method further comprises: calculating a second running time of a second task occupying the CPU; the second task is another task in the queue, the second task is a high priority task, and the second running time is less than a second reference time; wherein the second reference time is a running time calculated according to a reference weight corresponding to the priority level of the second task.

8. The method of any one of claims 1-7, wherein a first gap corresponding to the first weight mapping table is less than a second gap corresponding to the second weight mapping table; wherein the first gap is the gap between the minimum weight and the maximum weight in the first weight mapping table; and the second gap is the gap between the minimum weight and the maximum weight in the second weight mapping table.

9. An electronic device, comprising: The electronic device comprises: a processor for executing a computer program or instructions in a memory to implement the method of any of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises a stored program, wherein the program, when executed by a processor, implements the method of any of claims 1-8.

11. A chip system, characterized by comprising: a communication interface for inputting and / or outputting data; a processor for executing a computer executable program such that a device in which the chip system is installed performs the method of any of claims 1-8.

Images