A real-time task scheduling optimization method for SMP systems

Abstract

The present invention discloses a real-time task scheduling optimization method for an SMP system, which specifically includes the following steps: Linux kernel startup; when the scheduler is initialized, the CPU cores in the SMP system are grouped; the default values ​​of period and runtime are modified; the timer rt_period_timer is initialized; when a real-time task starts to run on the CPU core, the real-time task running time of the current CPU core is recorded, and the scheduler obtains the period value of the current CPU core and sets it as the timer timeout time of the current CPU core, and then starts the timer; each scheduling node calculates the running time of the real-time task on the CPU core, and if it exceeds the runtime of the current CPU core, the real-time task is stopped and the ordinary task is run. The present invention increases the rationality of task scheduling and CPU resource utilization.

Description

Technical Field

[0001] The invention relates to a real-time task scheduling technology for a multiprocessor, and in particular to a real-time task scheduling optimization method for an SMP system. Background Art

[0002] In the Linux kernel task scheduling mechanism, the scheduling of real-time tasks has the following characteristics:

[0003] First of all, in the Linux kernel task scheduling, the scheduling order of real-time tasks is superior to that of ordinary tasks. During the running of ordinary tasks, once a real-time task is awakened and added to the ready queue, preemption will occur. The scheduler will interrupt the running of the current ordinary task and switch to scheduling the real-time task.

[0004] In addition, the current real-time task scheduling usually adopts two scheduling strategies: SCHED_FIFO and SCHED_RR. Both scheduling strategies are based on the priority of real-time tasks. Real-time tasks with higher priorities are scheduled first. When the SCHED_FIFO scheduling strategy is used, real-time tasks of the same priority are scheduled in a first-in-first-out manner, and the first ready task is scheduled first; when the SCHED_RR scheduling strategy is used, real-time tasks of the same priority are scheduled in turn using the time slice rotation method.

[0005] Since the scheduling order of Linux real-time tasks is superior to that of ordinary tasks, if there are both real-time tasks and ordinary tasks in the task ready queue of a CPU core, no matter which of the above strategies is adopted, the real-time task will be scheduled first and will always occupy CPU resources to run. If the real-time task runs for too long, ordinary tasks will not be scheduled for a long time. In serious cases, it may even cause the entire system to become unresponsive.

[0006] At present, in order to avoid the above-mentioned real-time tasks occupying the CPU all the time, resulting in the phenomenon that ordinary tasks cannot be scheduled for a long time, the Linux kernel has also introduced the RT Throttling mechanism. The idea of ​​RT Throttling is to control the CPU to allocate a fixed runtime to the real-time task within a certain time period (period), and the runtime runtime is less than the time period period, so as to ensure that the CPU reserves a certain time for scheduling ordinary tasks within the time period (period), thereby avoiding the situation that the real-time task always occupies the CPU to run. In the existing RT Throttling, the Linux kernel provides two kernel parameters for users to flexibly modify period and runtime: kernel.sched_rt_period_us—represents the CPU running cycle time (period) of the RT Throttling mechanism, the default value is 1000000us, that is, 1s; kernel.sched_rt_runtime_us—represents the maximum time (runtime) that can be used to run real-time tasks within the CPU running cycle time (period), the default value is 9500000us, that is, 0.95s. That is to say, under the default system settings, through the Rt Throttling mechanism, 0.05s can be reserved for running ordinary tasks within a 1-second operating cycle, thus avoiding the situation where ordinary tasks cannot be scheduled.

[0007] However, in the existing RT Throttling mechanism, the period and runtime on each CPU core are consistent, and multiple CPU cores in the SMP system are not distinguished. In the SMP system, a computer does not have only one CPU, but a group of CPU cores are gathered, and all CPU cores share the memory subsystem and bus structure. Therefore, the implementation of RT Throttling in the SMP system does not distinguish between CPU cores, but uniformly sets the same period and runtime values ​​for all CPU cores, that is, the period and runtime on each CPU core are the same. This setting not only lacks flexibility, but also has some hidden dangers in extreme cases. For example, in a certain period of time, there are a large number of real-time tasks in the system, and there are some real-time tasks and ordinary tasks waiting to be scheduled in the ready queue of each CPU core. Different tasks have different requirements for scheduling time. It is inevitable that real-time tasks in some CPU core scheduling queues require more scheduling time, while ordinary tasks in other CPU core scheduling queues need to arrange more scheduling time. Therefore, it is difficult to find a suitable setting to meet the task scheduling requirements on all CPU cores at the same time. In addition, if the runtime is set too low, it may affect the real-time performance of some real-time tasks on the CPU cores. If the runtime is set too high, it may cause some ordinary tasks on the CPU cores to be slow due to short running time, resulting in problems such as unresponsiveness. Summary of the invention

[0008] The purpose of the present invention is to provide a real-time task scheduling optimization method for an SMP system to solve the problem that the existing real-time task scheduling method based on the SMP system cannot distinguish between the period and runtime of multiple CPU cores, resulting in the inability to configure appropriate period and runtime to simultaneously meet the task scheduling requirements on all CPU cores.

[0009] To solve the above technical problems, the purpose of the present invention is achieved as follows:

[0010] A real-time task scheduling optimization method for an SMP system, characterized in that it specifically comprises the following steps:

[0011] S1. When the Linux kernel starts to initialize the scheduler, the CPU cores in the SMP system are grouped: each group of CPU cores is called a CPU group;

[0012] S2. Set different period and runtime values ​​for each CPU group.

[0013] S3. Initialize timer rt_period_timer: rt_period_timer and timeout processing method are set to the relevant settings under the RT Throttling mechanism;

[0014] S4. When a real-time task starts to run on a certain CPU core, the real-time task running time of the current CPU core starts to be recorded. At the same time, the scheduler obtains the period value of the current CPU core, sets the period value of the current CPU core to the timeout time of the timer of the current CPU core, and then starts the timer.

[0015] S5. Each scheduling node calculates the running time of the real-time task on the CPU core and compares it with the runtime value corresponding to the current CPU core. If the running time exceeds the runtime of the current CPU core, the real-time task of the current CPU core is terminated and the normal task is run instead.

[0016] The method further includes step S6, the specific content of which is:

[0017] After terminating the real-time task of the current CPU core and running the ordinary task, when the time reaches period, the timer rt_period_timer on the current CPU core expires, and its timeout processing function performs judgment and setting, operates the current CPU core to abandon the ongoing ordinary task scheduling, returns to step S5, and continues to start scheduling the real-time task.

[0018] Among them, in step S2: a new kernel parameter is added to the Linux kernel, and the specific CPU group or single CPU core to be modified is specified by the new kernel parameter. After the Linux kernel is started, the period value and runtime value of the specified CPU group or CPU core are modified respectively by kernel.sched_rt_period_us and kernel.sched_rt_runtime_us.

[0019] Among them, when the scheduler in step S1 is initialized, the specific process of grouping the CPU cores in the SMP system is:

[0020] S11, obtain the number of CPU cores nr_cpu_ids of the SMP system, and determine whether it exceeds the maximum number of groups 32;

[0021] S12, if not greater than 32, divide the CPU cores into nr_cpu_ids groups;

[0022] Otherwise, the number of CPU cores is divided into 32 groups. The maximum number of CPU cores in each CPU group is the sum of the value of nr_cpu_ids / 32 and 1. The CPU members in the CPU group are recorded as CPUn, where n = 0, 1, 2, ..., nr_cpu_ids-1;

[0023] S13. Initialize a structure array to represent the grouping. The structure array includes: the number of CPU cores, CPU ID, runtime and period.

[0024] The new kernel parameters include kernel.sched_rt_cpu_zone and kernel.sched_rt_cpu_core: kernel.sched_rt_cpu_zone is used to specify a specific CPU group to be modified; kernel.sched_rt_cpu_core is used to specify a single CPU core to be modified.

[0025] In the real-time task scheduling optimization method for the SMP system of the present invention, real-time tasks with strict real-time requirements or long running time can be placed on the CPU core with a large proportion of runtime for real-time tasks within the period period, while real-time tasks with very short running time or ordinary tasks with strict processing speed requirements can be placed on the CPU core with a small proportion of runtime. This not only increases the rationality of task scheduling and CPU resource utilization, but also avoids the problems of real-time performance of real-time tasks and slow processing speed and unresponsiveness of ordinary tasks due to possible unreasonable scheduling.

[0026] The real-time task scheduling optimization method for the SMP system of the present invention avoids the following problems in extreme cases: the unified runtime / period ratio is set too low, affecting the real-time performance of real-time tasks on some CPU cores; or the runtime / period ratio is set too high, resulting in unresponsiveness caused by the short running time and slow processing speed of ordinary tasks on some CPU cores. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0028] Figure 1 A flowchart of the real-time task scheduling optimization method of the present invention;

[0029] Figure 2 A flowchart of a real-time task scheduling optimization method according to an embodiment of the present invention;

[0030] Figure 3A flow chart for grouping CPU cores of the present invention;

[0031] Figure 4 It is an effect diagram of the real-time task scheduling optimization method of the present invention. DETAILED DESCRIPTION

[0032] The technical scheme in the embodiment of the present invention is described clearly and completely below in conjunction with the accompanying drawings in the embodiment of the present invention. In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present invention, so the present invention is not limited by the specific embodiments disclosed below.

[0033] like Figure 1 As shown, a real-time task scheduling optimization method for an SMP system specifically includes the following steps:

[0034] S1. When the Linux kernel starts to initialize the scheduler, the CPU cores in the SMP system are grouped (a single group or multiple groups): each group of CPU cores is called a CPU group.

[0035] When the scheduler in step S1 is initialized, the specific process of grouping the CPU cores in the SMP system is as follows: Figure 3 As shown, during the scheduler initialization sched_init process,

[0036] S11, obtain the number of CPU cores nr_cpu_ids of the SMP system, and determine whether it exceeds the maximum number of groups 32;

[0037] S12. If it is not greater than 32, the CPU cores are divided into nr_cpu_ids groups; that is, each CPU core is a separate group;

[0038] Otherwise, the number of CPU cores is divided into 32 groups. The maximum number of CPU cores contained in each CPU group is the sum of the value of nr_cpu_ids / 32 and 1, that is, the number is ((nr_cpu_ids / 32)+1). The CPU members in the CPU group are recorded as CPUn, where n=0,1,2,…,nr_cpu_ids-1. Assuming there are 65 cores in total, these 65 cores are divided into 32 groups. Only the first group contains three cores, namely CPU0, CPU1, and CPU2. The second group contains: CPU3, CPU4, and so on. The 32nd group contains CPU63 and CPU64.

[0039] S13. Initialize a structure array to represent the grouping. The structure array includes: the number of CPU cores, CPU ID, runtime and period.

[0040] The present invention uses 32 as the maximum number of groups, with the following considerations:

[0041] 1. In actual usage scenarios, 32 CPU groups with different runtimes and periods can basically meet user needs.

[0042] 2. In the current 32-bit or 64-bit operating system, int type values ​​occupy 4 bytes, that is, 32 bits, which is convenient for subsequent methods to set the runtime and period values ​​of each group of CPUs. For details, please refer to the subsequent methods for setting runtime and period.

[0043] S2. Set different period and runtime values ​​for each CPU group or each CPU core. In the present invention, the runtime and period of the CPU members in the CPU group can be set uniformly, or the runtime and period of each CPU can be set individually, that is, the runtime and period of all CPU members in the same CPU group can be the same or different. For example, when the scheduler is initialized, each group of CPUs is distinguished. Specifically, the period of all groups can be consistent, and the default is 1000000, but the runtime of each group is inconsistent. The first group is 950000, the second group is 940000, the third group is 930000, and so on. It can also be adjusted according to the number of groups. Wherein, in step S3: add new kernel parameters, specify the specific CPU group or single CPU core to be modified through the new kernel parameters, and after the Linux kernel is started, modify the period value and runtime value of the specified CPU group or CPU core respectively through kernel.sched_rt_period_us and kernel.sched_rt_runtime_us, that is, modify the period and runtime of each CPU group or each CPU core through the new kernel parameters, which is the normal operation stage after the kernel is started. Wherein, the new kernel parameters include kernel.sched_rt_cpu_zone and kernel.sched_rt_cpu_core: specify the specific CPU group to be modified through kernel.sched_rt_cpu_zone; specify the single CPU core to be modified through kernel.sched_rt_cpu_core, and then the period and runtime set by the parameters kernel.sched_rt_period_us and kernel.sched_rt_runtime_us will only take effect on the specified CPU group or CPU core, and will not affect the settings on other CPU cores. If you only use kernel.sched_rt_cpu_zone to specify the CPU group and then set the period and runtime, the period and runtime values ​​on all CPU cores in this group will be consistent. Then we can use kernel.sched_rt_cpu_core to specify a specific CPU core. This core can be in the CPU group set previously, so that the runtime and period of the CPU members in the group can be different. The two newly added parameters can be used separately or in combination, so that the runtime and period of all CPU members in the same CPU group can be the same or different.

[0044] When you set the kernel.sched_rt_cpu_zone or kernel.sched_rt_cpu_core value through systcl, the kernel recognizes the user-set value as a specific CPU core and saves it. Then, when you set the kernel.sched_rt_period_us and kernel.sched_rt_runtime_us values, the set values ​​only apply to the saved CPU core.

[0045] For example:

[0046] 1. First, set the value of kernel.sched_rt_cpu_core to 4, specifying CPU4, and then set the value of kernel.sched_rt_period_us to 1000000, and the value of kernel.sched_rt_runtime_us to 950000. This will set the period of CPU4 to 1 second and the runtime to 0.95 seconds.

[0047] 2. Set the value of kernel.sched_rt_cpu_zone to 0x0000 0001, specify the first CPU group, set the value of kernel.sched_rt_period_us to 1000000, and set the value of kernel.sched_rt_runtime_us to 950000. This means that the period value on the CPU core in the first CPU group is set to 1000000 (1 second) and the runtime value is set to 950000 (0.95 seconds).

[0048] 3. In this embodiment, kernel.sched_rt_cpu_zone is an 8-digit hexadecimal value, which is exactly 32 bits after conversion to binary. Each bit corresponds to a CPU group. For example, 0x00000005 is converted to binary as 0000 00000000 0000 0000 0000 0000 0101, which represents the runtime and period values ​​of the CPU cores in the first and third groups.

[0049] 4. Therefore, when specifying groups through the kernel.sched_rt_cpu_zone parameter, you can specify multiple groups at the same time, that is, you can set the period and runtime values ​​of CPU cores in multiple groups at the same time. However, through the kernel.sched_rt_cpu_core parameter, you can only set the period and runtime values ​​of one CPU core at a time. The two solutions can be used together.

[0050] Through the above modifications, in the SMP system, the scheduler will arrange the real-time tasks and ordinary tasks more reasonably, and also improve the utilization efficiency of CPU resources. Most importantly, the optimized RT Throttling mechanism can avoid problems such as unresponsiveness caused by the unified runtime / period ratio being set too low in some extreme cases, affecting the real-time performance of real-time tasks on some CPU cores, or the runtime / period ratio being set too high, resulting in the ordinary tasks on some CPU cores running less and processing slower.

[0051] S3. Initialize timer rt_period_timer: rt_period_timer and timeout processing method are set as related settings under RT Throttling mechanism.

[0052] Under the existing RT Throttling mechanism, Linux calls the init_rt_bandwidth() method defined in the rt scheduler in the scheduler initialization sched_init() method, and initializes an rt_period_timer through this method. The timeout callback function of the rt_period_timer, sched_rt_period_timer, will check whether to set the rt_queued flag in the ready queue rt_rq of the rt_sched_class scheduling class to "1", thereby deciding whether to re-add the rt_sched_class scheduling class to the scheduler. In addition, the callback function will reset the next timeout time to the period time "period" we specify.

[0053] The code implementation of the whole process is in kernel / sched / rt.c.

[0054]

[0055]

[0056] After the timer is initialized, it will be activated when an rt task joins the ready queue rt_rq. When the timer times out, its callback function sched_rt_period_timer() will be executed to do two things:

[0057] Reset the next timeout period of the timer to period;

[0058] Check and decide whether to add the rt_sched_class scheduling class back to the scheduling class list.

[0059] The main code in the kernel is as follows:

[0060]

[0061]

[0062] In this embodiment, steps S1, S2, and S3 are in the process of the Linux kernel starting the program.

[0063] S4. When a real-time task starts to run on a certain CPU core, the real-time task running time of the current CPU core starts to be recorded. At the same time, the scheduler obtains the period value of the current CPU core, sets the period value of the current CPU core to the timeout time of the timer of the current CPU core, and then starts the timer.

[0064] S5. Each scheduling node (i.e., clock tick or task exit rt_rq) calculates the running time of the real-time task on the CPU core and compares it with the runtime value corresponding to the current CPU core. If the running time exceeds the runtime of the current CPU core, i.e., rt throttled, the real-time task of the current CPU core is terminated and ordinary tasks are run instead. Among them, the scheduling nodes of the Linux kernel scheduler (including clock tick, task exit, etc.) are mainly used to determine whether task switching is required. In simple terms, the scheduler needs to determine whether the current running task time or the task status in the scheduling queue has changed every once in a while, and then decide whether to switch tasks.

[0065] S6. After the real-time task of the current CPU core is terminated and the ordinary task is run, when the time reaches period, the timer rt_period_timer on the current CPU core expires, and its timeout processing function performs judgment and setting, operates the current CPU core to abandon the ongoing ordinary task scheduling, restarts the real-time task scheduling, returns to step S5, and continues to start scheduling the real-time task to enter the next period.

[0066] Embodiment 1

[0067] Here is an application scenario of the present invention: there is a real-time task that has a high real-time requirement, and after the task is scheduled and starts running, it takes a long time to run. According to the characteristics of the task, the task is more suitable to be placed on a CPU core with a large period and runtime value and a large runtime / period ratio, so that the CPU can have more time to run the real-time task within a period, and will not be interrupted due to runtime exhaustion.

[0068] In this case, the user's operation process is as follows (such as Figure 2):

[0069] 1. First, compare the period and runtime values ​​of each CPU core to find the optimal CPU core, assuming that it is not found.

[0070] 2. Select a fixed CPU core, assuming it is CPU0, and then modify the period and runtime values ​​of CPU0 through the parameters provided by the kernel to ensure that the modified CPU core is more suitable for the operation of this real-time task. The scheduler modifies the period and runtime values ​​of CPU0 to the values ​​set by the user.

[0071] 3. When writing a real-time task program, we need to set a suitable scheduling policy and priority for the task, and we can bind the task to CPU0 by setting the CPU affinity of the task. After the task is awakened in the Linux kernel, it is placed in the ready queue of CPU0, and CPU0 starts running to this extent, and then sets the timer rt_period_timer timeout to period and starts the timer. Among them, the CPU affinity method is: the Linux kernel provides methods such as sched_setaffinity() for the application to set CPU affinity, which is consistent with the existing CPU affinity method.

[0072] 4. Wait for the task to finish running and check the running results. During the running of the real-time task, each scheduling node determines whether the running time of the real-time task on CPU0 exceeds the set runtime. If it exceeds, the real-time task running is terminated. After terminating the real-time task running of the current CPU core and running the ordinary task, when the time reaches period, the timer rt_period_timer on the CPU0 core expires, and its timeout processing function operates the current CPU0 core, returns to step 3 "CPU0 starts running this degree, and then sets the timer rt_period_timer timeout time to period and starts the timer, and continues to schedule real-time tasks to enter the next cycle.

[0073] The present invention optimizes the RT Throttling mechanism so that the periods on different CPU cores are different (such as Figure 4 As shown in the figure, the runtime available for real-time tasks in the cycle is also different. Through the optimized mechanism, we can achieve the following technical effects:

[0074] 1. Put the real-time tasks with long running time on CPU cores with large period and runtime values ​​and large runtime / period ratios. This ensures the running time of the real-time tasks and avoids the situation where the runtime is exhausted and forced to be interrupted.

[0075] Second, put the real-time tasks with very short running time on the CPU core with a smaller runtime / period ratio to avoid affecting the determinism of its own response time due to the long running time of other real-time tasks;

[0076] 3. Put ordinary tasks with strict processing speed requirements on CPU cores that have a large amount of time to run ordinary tasks within the period, that is, on CPU cores with a smaller runtime / period ratio, to avoid problems such as unresponsiveness caused by the short running time and slow processing speed of ordinary tasks when there are a large number of real-time tasks.

[0077] 4. When the user compares the period and runtime values ​​of each CPU core in the SMP system and finds that the current task is not suitable to be run on any CPU core, the user can select a CPU core, modify its period and runtime values, and then bind the task to this CPU core for scheduling.

[0078] It should be understood that the above specific embodiments of the present invention are only used to illustrate or explain the principles of the present invention, and do not constitute a limitation of the present invention. Therefore, any modifications, equivalent substitutions, improvements, etc. made without departing from the spirit and scope of the present invention should be included in the protection scope of the present invention. In addition, the appended claims of the present invention are intended to cover all changes and modifications that fall within the scope and boundaries of the appended claims, or the equivalent forms of such scope and boundaries.

Claims

1. A real-time task scheduling optimization method for an SMP system, characterized in that: The specific steps include: S1. When the Linux kernel starts to initialize the scheduler, the CPU cores in the SMP system are grouped: each group of CPU cores is called a CPU group; S2. Set different period and runtime values ​​for each CPU group. S3, initialize the timer rt_period_timer, rt_period_timer and the timeout processing method are set as follows: Linux calls the init_rt_bandwidth() method defined in the rt scheduler in the scheduler initialization sched_init() method, and initializes an rt_period_timer timer through this method. The sched_rt_period_timer in the timeout callback function of the rt_period_timer timer will check whether to set the rt_queued flag in the ready queue rt_rq of the rt_sched_class scheduling class to "1", thereby deciding whether to re-add the rt_sched_class scheduling class to the scheduler; S4. When a real-time task starts running on a certain CPU core, the real-time task running time of the current CPU core starts to be recorded. At the same time, the scheduler obtains the period value of the current CPU core, sets the period value of the current CPU core to the timeout time of the timer of the current CPU core, and then starts the timer. S5. Each scheduling node calculates the running time of the real-time task on the CPU core and compares it with the runtime value corresponding to the current CPU core. If the running time exceeds the runtime of the current CPU core, the real-time task of the current CPU core is terminated and the normal task is run instead.

2. The real-time task scheduling optimization method for SMP system according to claim 1, characterized in that: The step S6 is also included. The specific content of the step S6 is: After terminating the real-time task of the current CPU core and running the ordinary task, when the time reaches period, the timer rt_period_timer on the current CPU core expires, and its timeout processing function performs judgment and setting, operates the current CPU core to abandon the ongoing ordinary task scheduling, returns to step S5, and continues to start scheduling the real-time task.

3. The real-time task scheduling optimization method for SMP system according to claim 1, characterized in that: In step S2: a new kernel parameter is added to the Linux kernel, and the specific CPU group or single CPU core to be modified is specified by the new kernel parameter. After the Linux kernel is started, the period value and runtime value of the specified CPU group or CPU core are modified respectively by kernel.sched_rt_period_us and kernel.sched_rt_runtime_us.

4. The real-time task scheduling optimization method for SMP system according to claim 1, characterized in that: When the scheduler in step S1 is initialized, the specific process of grouping the CPU cores in the SMP system is as follows: S11, obtain the number of CPU cores nr_cpu_ids of the SMP system, and determine whether it exceeds the maximum number of groups 32; S12, if not greater than 32, divide the CPU cores into nr_cpu_ids groups; Otherwise, the number of CPU cores is divided into 32 groups. The maximum number of CPU cores in each CPU group is the sum of the value of nr_cpu_ids / 32 and 1. The CPU members in the CPU group are recorded as CPUn, where n=0, 1, 2, ..., nr_cpu_ids-1. S13. Initialize a structure array to represent the grouping. The structure array includes: the number of CPU cores, cpuid, runtime and period.

5. The real-time task scheduling optimization method for SMP system according to claim 3, characterized in that: The new kernel parameters include kernel.sched_rt_cpu_zone and kernel.sched_rt_cpu_core: kernel.sched_rt_cpu_zone is used to specify the specific CPU group to be modified; kernel.sched_rt_cpu_core is used to specify the single CPU core to be modified.

Images