CN-121681077-B - System certainty enhancement method

CN121681077BCN 121681077 BCN121681077 BCN 121681077BCN-121681077-B

Abstract

The invention discloses a system certainty enhancing method which comprises the following steps of S1, defining a core judgment standard, defining a key CPU and a key real-time task, detecting ready states of the key CPU and the key real-time task, triggering a periodical forced scheduling mechanism if the ready states exist, S2, carrying out certainty modification of a scheduler, namely cutting an unnecessary path, simplifying a user state preemption path, providing an SMP forced scheduling mechanism and a silent background thread, S3, carrying out real-time interrupt processing, namely setting the key interrupt as high priority, isolating the key CPU, limiting the bottom half, activating the periodical forced scheduling mechanism, S4, carrying out certainty modification of a protocol stack, namely optimizing four aspects of NAPI polling, congestion fragmentation, qdisc delay and filtering rules, S5, carrying out priority signal processing, and S6, carrying out certainty modification of a container, namely removing CGroup limit, binding the key CPU, disabling and port mapping, using native IO and closing a non-core daemon.

Inventors

KONG JINZHU
WU QINGBO
GUO HAO
WU CHUNGUANG
GAO YUANJUN
LIU GUISHAN
XIA RUOBING

Assignees

麒麟软件有限公司

Dates

Publication Date: 20260508
Application Date: 20260212

Claims (9)

1. The system certainty enhancing method is characterized in that for the uncertainty of six aspects of interruption, bottom half, scheduling, preemption, signal transmission and protocol stack when a system program is executed, the delay and jitter of a key real-time task are reduced through six means of core judgment reference definition, kernel scheduling, interrupt processing, network protocol stack, signal processing and container virtualization, wherein the core judgment reference definition is realized through a step S1, the kernel scheduling is realized through a step S2, the interrupt processing is realized through a step S3, the network protocol stack is realized through a step S4, the signal processing is realized through a step S5, and the container virtualization is realized through a step S6; Step S1, defining a core judgment standard, namely defining a key CPU and a key real-time task, detecting the ready state of the key CPU and the key real-time task, and triggering a periodic forced scheduling mechanism if the ready state exists; Step S2, deterministic reconstruction of a scheduler, namely cutting unnecessary paths, simplifying user-state preemption paths, and providing an SMP forced scheduling mechanism and a silent background thread, wherein the SMP forced scheduling mechanism is realized and concretely comprises the following steps: In the include/linux/sched.h, using rq_has_critical_task () function in set_tsk_need_ resched () function to judge whether there is a critical real-time task in the ready queue of the current CPU, if there is, immediately executing __ schedule () function, if there is not, not executing; In the arch/arm64/kernel/smp.c, judging whether the current CPU is a key CPU by using an is_critical_cpu () function in a do_handle_IPI () function, if so, judging whether a key real-time task exists in a ready queue of the current CPU by using an rq_has_critical_task () function, if so, immediately executing __ schedule () function, and if not, keeping original code logic; In IPI_CALL_FUNC, IPI_TIMER and IPI_IRQ_WORK processing logic, using rq_has_critical_task () function to judge whether the current CPU is a key CPU, if so, masking the original code logic, if not, executing normally; Step S3, real-time interrupt processing, namely setting the key interrupt as high priority, isolating the key CPU, limiting the bottom half part and activating a periodic forced scheduling mechanism; step S4, protocol stack deterministic transformation, namely optimizing four aspects of NAPI polling, congestion fragmentation, qdisc delay and filtering rules to ensure real-time performance; step S5, priority signal processing, namely defining the signal processed by a sender or a receiver as a high-priority signal, preferentially processing the high-priority signal, and activating a periodic forced scheduling mechanism before processing the low-priority signal; and S6, transforming the container certainty, namely, removing CGroup limit, binding key CPU, disabling NAT and port mapping, using the native IO and closing the non-core daemon.
2. The system deterministic enhancement method according to claim 1, wherein the definition of the critical CPU in step S1 comprises the steps of: Step S111, in kernel/sched/isolation.c, using __ setup function to increase the processing function rt_cpu_setup of rt_cpu, wherein the parameter is rt_cpu_str; Step S112, adding a static cpumask _var_t variable, named as rt_cpu_mask, in a kernel/sched/isolation.c; Step S113, in the rt_cpu_setup processing function, referring to isolcpus processing logic to analyze and process the rt_cpu, and assigning a processing result to the rt_cpu_mask; step S114, call housekeeping _ isolcpus _setup (), transfer the existing parameter rt_cpu_str into the processing function; Step S115, adding a parameter rt_cpu=3 to the kernel start parameter, and enabling the definition of the key CPU through the parameter; Step S116, adding an is_critical_cpu function in kernel/sched/isolation.c, wherein the parameter is the ID of cpu, namely cpu_id; step S117, in the is_critical_cpu function, judging whether the function parameter cpu_id is in the rt_cpu_mask, if so, returning to 1, and if not, returning to 0.
3. The system deterministic enhancement method according to claim 2, wherein the definition of critical real-time tasks in step S1 comprises the steps of: Step S121, adding an is_critical_rt_task function in a kernel/sched/core.c, wherein parameters are task_struct structures; Step S122, judging whether the task is a FIFO or RR task by using rt_prio, if yes, judging whether prio is less than or equal to 20, if yes, returning to 1, and if no, returning to 0; Step S123, using dl_prio to judge whether the task is DL task, if yes, returning to 1, otherwise, returning to 0.
4. The system deterministic enhancement method according to claim 3, wherein the periodic forced scheduling mechanism in step S1 is to determine, in the critical CPU, whether there is a critical real-time task in the ready queue in the current CPU, and if so, send an IPI interrupt to the corresponding CPU.
5. The system deterministic enhancement method according to claim 1, wherein the clipping unnecessary path in step S2 specifically comprises the steps of: Step S211, in a kernel/time/tick-common.c file, judging whether a key real-time task exists in a ready queue of a current CPU by using an rq_has_critical_task () function in a tick_handle_periodic () function, if so, adjusting the execution of the tick_periodic () function in the function, and then directly returning, and if not, normally executing; Step S212, judging whether a key real-time task exists in a ready queue of a current CPU in a kernel/shced/core.c file by using an rq_has_critical_task () function in a schedule_tic () function, if so, not executing load balancing, and if not, executing normally; In step S213, in the kernel/time/timer.c file, the rq_has_critical_task () function is used in the update_process_time () function to judge whether a key real-time task exists in the ready queue of the current CPU, if so, the timeout processing work and the RCU waiting work are not executed, and if not, the normal execution is performed.
6. The system deterministic enhancement method according to claim 5, wherein the simplifying the user state preemption path in step S2 specifically comprises the steps of: The rq_has_critical_task () function is used in the kernel/entry/common.c file exit_to_user_mode_loop () function to determine whether there is a critical real-time task in the current CPU ready queue, if so, uprobe, livepatch, signal processing and notify are not performed, and if not, execution is performed.
7. The system deterministic enhancement method according to claim 1, wherein the restriction on the bottom half in step S3 is that if the current context is an interrupt context and the current CPU is within a critical CPU, the maximum execution frequency is restricted and there is a critical real-time task in the ready queue of the current CPU, then execution of soft interrupt is not allowed.
8. The system deterministic enhancement method according to claim 1, wherein the Qdisc delay optimization in step S4 further comprises skb application delay optimization.
9. The system deterministic enhancement method according to claim 8, wherein the filtering rule optimization in step S4 comprises the steps of writing a user state filtering rule optimization tool, disabling netfilter modules and functions, and simplifying iptables rules.

Description

System certainty enhancement method Technical Field The invention relates to the technical field of operating systems, in particular to a system certainty enhancing method. Background With the development of technologies such as AI, 5G and cloud computing, an industrial control system is gradually changed from ISA95 to cloud edge end integration, the traditional RTOS system cannot meet the requirements of the industrial control system under the emerging technology, a Linux system is favored by equipment developers of various industrial control systems, but the Linux system is designed for the general field, the resource utilization rate and the throughput rate of equipment are mainly considered, and the problem that the real-time performance is difficult to eradicate exists. Though the Linux system can support soft real-time characteristics through Preempt _rt in a harmless manner, in a scene with high jitter requirements, such as a scene of high-precision manufacturing, the requirements cannot be met, the root cause of the Linux system is that the Linux system is interrupted, the bottom half part is provided with more uncertainties in aspects of scheduling, preemption, signal processing and network protocol stacks, for example, the execution time of the bottom half part can be 2ms, which is disastrous for real-time application, for this purpose, the overall scheduling process of Linux needs to be deterministically optimized, a Linux determinism enhancement framework is developed, and the jitter compression of the system is realized within 10 microseconds. The Preempt _RT system can achieve microsecond scheduling under the condition that application is not aware, but real-time task scheduling jitter still exists due to the scheduling and preemption mechanism of Linux. Although the Xenomai system can meet the requirement of high-precision manufacturing scenes on jitter, the scheme introduces RTOS, so that real-time application is difficult to reuse Linux ecology, and development is limited at the current stage of rapid development of AI and cloud computing. Embedded virtualization schemes, such as Jailhouse, xen, essentially like Xenomai, require the introduction of an RTOS. In the prior art, as shown in fig. 1, the program is affected by uncertainty of interrupt, bottom half, scheduling and preemption before execution, and is affected by signal transmission and protocol stack after execution. On a whole call path, each stage has a problem to be solved. In the interrupt stage, the interrupt is the key of ensuring time certainty of a real-time task, and is the driving force for responding to external data, and various interrupts such as block device interrupt, network card interrupt, timer interrupt, serial port interrupt, USB interrupt, display card interrupt, audio interrupt and IPI interrupt usually exist in the device. Among these interrupts, timer and network card interrupts are higher priority interrupts for conventional industrial control traffic, and other interrupts are normal priority interrupts. In Linux systems, the concept of interrupt priority does not exist, and in order to ensure that more important interrupts can be processed preferentially, special processing needs to be performed on interrupts with specific priority. In the bottom half stage, the Linux system improves the response speed of the interrupt, reduces the influence of the interrupt on the system, and divides the interrupt into a top half and a bottom half. The system comprises a top half part, a bottom half part, a 5.10 kernel, a timer, a network transceiver, a block device, a training process, a scheduler, a high-precision clock and an RCU, wherein the top half part is closed for interrupt and preemption prohibition, the quick execution is carried out and then the rest of complex work is carried out by the bottom half part, the bottom half part is provided with multiple types, 10 types are respectively tasklet high/low priority, the timer, the network transceiver, the block device, the training process, the scheduler, the high-precision clock and the RCU, the maximum time can be executed for 2ms, the interrupt and preemption are opened and closed during the execution, the execution time is extremely uncontrollable, and the system belongs to a deterministic heavy disaster area and needs important restriction. In the scheduling stage, two types of schedulers are generally responsible for scheduling, namely a periodic scheduler and a core scheduler, wherein the periodic scheduler is Linux, and generates HZ clock interrupts every 1 second, and each clock interrupt executes a tick_handle_period () function, and in the function, timer timeout, RCU (remote control unit), load balancing and uncontrolled processing time are generally required to be processed. When the Preempt _RT patch is used by the Linux kernel, the HZ mode is converted into NOHZ mode, at the moment, no interrupt is fixedly generated, but the interrupt is still needed