System determinism enhancement method

Abstract

The application discloses a system certainty enhancement method, comprising the following steps: step S1, core judgment reference definition: defining a key CPU and a key real-time task, detecting the key CPU and the key real-time task ready state, and triggering a periodic forced scheduling mechanism if the key CPU and the key real-time task ready state exist; step S2, scheduler certainty modification: cutting unnecessary paths, simplifying user state preemption paths, providing an SMP forced scheduling mechanism and a silent background thread; step S3, real-time interrupt processing: setting a key interrupt as a high priority, isolating a key CPU and limiting a bottom half, and activating a periodic forced scheduling mechanism; step S4, protocol stack certainty modification: optimizing from four aspects of NAPI polling, congestion fragmentation, Qdisc delay and filtering rules; step S5, priority signal processing; and step S6, container certainty modification: removing CGroup limitation, binding a key CPU, disabling NAT and port mapping, using native IO and closing non-core daemon processes.

Description

Technical Field

[0001] This invention relates to the field of operating system technology, and in particular to a method for enhancing system determinism. Background Technology

[0002] With the development of technologies such as AI, 5G, and cloud computing, industrial control systems are gradually shifting from ISA95 to a cloud-edge-device integrated model. Traditional RTOS systems are increasingly unable to meet the needs of industrial control systems under emerging technologies. Linux systems are gradually gaining favor among various industrial control system equipment manufacturers. However, Linux systems are designed for general-purpose applications, focusing on the resource utilization and throughput of devices, and have persistent problems in real-time performance. Although Linux systems can harmlessly support soft real-time characteristics through Preempt_RT, they cannot meet the requirements in scenarios with high jitter requirements, such as high-precision manufacturing. The fundamental reason is that Linux systems have many uncertainties in interrupts, bottom half execution, scheduling, preemption, signal processing, and network protocol stacks. For example, the execution time of the bottom half may be 2ms, which is disastrous for real-time applications. Therefore, it is necessary to perform deterministic optimization on the entire scheduling process of Linux and develop a Linux deterministic enhancement framework to achieve system jitter compression within 10 microseconds.

[0003] The Preempt_RT system can achieve microsecond-level scheduling without the application's awareness, but due to Linux's scheduling and preemption mechanisms, real-time task scheduling jitter still exists. While the Xenomai system can meet the jitter requirements of high-precision manufacturing scenarios, its introduction of an RTOS makes it difficult for real-time applications to reuse the Linux ecosystem, limiting its development in the current era of rapid AI and cloud computing advancements. Embedded virtualization solutions, such as Jailhouse and Xen, essentially require an RTOS, just like Xenomai.

[0004] In existing technologies, such as Figure 1 As shown, before program execution, it is affected by uncertainties such as interrupts, bottom halves, scheduling, and preemption; after execution, it is affected by signal transmission and the protocol stack. Along the entire call path, there are problems that need to be solved at each stage.

[0005] During the interrupt phase, interrupts are crucial for ensuring the deterministic timing of real-time tasks and are the driving force behind responses to external data. Devices typically contain various interrupts, such as block device interrupts, network card interrupts, timer interrupts, serial port interrupts, USB interrupts, graphics card interrupts, audio interrupts, and IPI interrupts. Among these, timer and network card interrupts are relatively high-priority interrupts for typical industrial control tasks, while the others are of ordinary priority. However, Linux systems do not have the concept of interrupt priority. To ensure that more important interrupts are processed first, special handling is required for interrupts of specific priorities.

[0006] In the bottom half stage, to improve interrupt response speed and reduce the impact of interrupts on the system, the Linux system divides interrupts into the top half and the bottom half. The top half disables interrupts and preemption, executes quickly, and then exits, leaving the remaining complex tasks to be performed by the bottom half. The bottom half has multiple types; in the 5.10 kernel, there are 10 types: high / low priority tasklets, timers, network transceivers, block devices, polling, schedulers, high-precision clocks, and RCU. Each execution can last up to 2ms. During execution, interrupts are enabled and preemption is disabled, making the execution time highly unpredictable. This is a major area of ​​deterministic behavior and requires strict control.

[0007] During the scheduling phase, there are typically two types of schedulers responsible for scheduling: the periodic scheduler and the kernel scheduler. The periodic scheduler generates HZ clock interrupts every second in Linux. Each clock interrupt executes the `tick_handle_periodic()` function, which typically handles timer timeouts, RCU, and load balancing; the processing time is unpredictable. When the Linux kernel uses the Preempt_RT patch, HZ mode is switched to NOHZ mode. In this case, interrupts are no longer generated regularly, but `tick_handle_periodic()` will still be executed due to other timer timeouts. The kernel scheduler uses the `schedule()` function, which allows processes to voluntarily relinquish the CPU. It needs to select the next process to run and perform a process context switch.

[0008] The preemption phase mainly consists of two steps. The first step is setting the process's TIF_NEED_RESCHED flag. At this point, the process is not yet preempted and continues to run. Preemption only actually occurs when it reaches certain scheduling points. The second step involves the actual execution of the preemption operation when a system call returns, an interrupt returns to user / kernel mode, or preemption is enabled. Preemption is divided into user-mode preemption, which occurs upon system call return (mainly executed by the function `exit_to_user_mode_prepare`) and interrupt return to user mode (mainly executed by the function `exit_to_user_mode_prepare`). Kernel-mode preemption occurs upon interrupt return to kernel mode (mainly executed by the function `preempt_enable`) and when preemption is enabled (mainly executed by the function `preempt_schedule_irq`). In the `exit_to_user_mode_prepare()` function, before returning to user mode, unpredictable time-dependent processes such as uprobe, livepatch, signals, and notify are executed.

[0009] During the signal transmission phase, Linux signal processing is sequential, and the processing time is not fixed. There may be signals corresponding to real-time tasks that need to be processed urgently, but the previous signal processing is still in the queue, which makes it impossible for real-time tasks to execute on time. Therefore, it is necessary to process the signals sent or received by real-time tasks with high priority.

[0010] During the protocol stack processing phase, when a task sends data, it first copies the data to the kernel layer within the process context, performs TCP / UDP header encapsulation, IP header encapsulation, fragments the data, converts it into skb blocks, and places them into the Qdisc buffer pool. Then, the device driver's `dev_queue_xmit()` function sequentially places each skb block into the network card's DMA memory, and the DMA sends out a batch of data at once. If the sending action occupies the process context for a long time, subsequent data packets will be sent via a software interrupt. When receiving data, the typical process is as follows: hardware DMA receives data packets (without CPU involvement), triggers the top half of an interrupt (performed in interrupt context, non-blocking), and performs protocol stack parsing using NAPI polling (batch packet reception to reduce interrupt overhead) + the bottom half of a software interrupt (receiving large numbers of packets) and places them into the application's receive queue buffer. The application layer receives the notification via `poll` or `epoll` and processes the information through the read function. Traditional Linux systems typically consider network card throughput to minimize the number of interrupts and reduce the impact on applications. However, in industrial control scenarios, it is necessary to receive and send packets as quickly as possible, and even more interrupts are acceptable.

[0011] In the above processing, the NAPI polling mechanism requires fixed intervals or fixed data packages to trigger, which increases the delay in receiving data packets. The default polling period is 2ms. The TCP SACK mechanism incurs variable time overhead for maintaining the O(n)-level SACK block list and for encapsulating TCP options at the receiving end. The overhead is extremely low when there is no out-of-order packet, and the more out-of-order packets there are, the longer the time becomes, directly lengthening the single packet processing link. This causes the packet reception delay jitter to increase from the 10μs level to the 100μs level. In the complex high-out-of-order network environment of industrial control, the SACK block list expands rapidly, and the overhead of traversing and assembling at the receiving end increases exponentially, causing the CPU utilization rate to soar and squeezing the CPU resources of real-time tasks, resulting in a delay in the response of real-time tasks. The TCP timestamp mechanism adds 1-10 microseconds of time consumption at the sending end and 10-20 microseconds at the receiving end. Moreover, the time consumption is not fixed and fluctuates greatly, which has a certain uncontrollable impact on the network transmission and reception of data packages in industrial control scenarios. The automatic adjustment of the receive buffer causes dynamic fluctuations in the buffer size and the receive window (RWND) during actual operation, resulting in single packet dwell delay. Latency and latency jitter are uncontrollable. Industrial control scenarios typically use multi-queue network cards. RSS is a multi-core load balancing mechanism that combines the Linux protocol stack with network card hardware collaboration. Its core is to hash and distribute network packets received by the network card to different CPU cores for processing, solving the bottleneck of single CPU packet reception and improving network performance in high-throughput scenarios. However, for real-time scenarios, fine-grained configuration is required; otherwise, scheduling jitter and cache invalidation risks will be introduced. When the application sends data, it dynamically requests skb and puts it into the Qdisc queue for transmission. This seemingly simple step has significant uncertainties. For example, requesting skb may cause sleep, which could lead to the real-time process being swapped out. There are various Qdisc transmission mechanisms, but Linux systems usually set it to CFQ to ensure throughput. In real-time control scenarios, this scheduling mechanism can cause critical control data to be affected by business data, thus increasing uncertainty. The netfilter / iptables mechanism introduces variable latency for packet traversal rule chains, preemption conflicts for kernel-mode hooks, and dynamic overhead for connection tracking (conntrack), which amplifies single-packet processing latency jitter (single-packet processing time <1μs without rules, ≈5μs for 10 ordinary rules, and ≈50μs for 100 rules; moreover, whether a rule is hit or which rule is hit can cause latency jitter to rise from the μs level to the ms level). In real-time control scenarios, the core principles of "minimum rule set + disabling unnecessary functions + CPU isolation" should be followed to reduce iptables overhead to a predictable fixed value, prioritizing determinism over functional completeness.

[0012] In addition, the Linux kernel provides several threads for each CPU, such as CPU hot-plugging (cpuhp), idle injection thread (idle_inject), process migration thread (migration), soft interrupt daemon thread (ksoftirqd), block device handling thread (kworker), and RCU handling thread (rcu). Although these mechanisms can increase the resource utilization of the Linux system, they are disastrous for scenarios that focus on real-time and deterministic operations, as they will seriously affect the predictability of the system.

[0013] Industrial control systems are evolving towards openness, networking, collaboration, and intelligence, with container technology becoming a key technology. Examples include Phoenix Contact's PLCnext and Codesys. The real-time performance of containers is crucial for industrial control systems. However, container CGroups mechanisms can lead to deterministic loss; container network virtualization amplifies transmission latency and jitter; and containerd-shim threads sharing the CPU with real-time tasks within the container increases the response latency of real-time tasks.

[0014] To address the execution uncertainty issue in systems (including Linux and RTOS), a system determinism enhancement framework needs to be designed in principle to make the execution path of critical tasks controllable throughout their entire lifecycle, achieving low jitter and high determinism system characteristics. Summary of the Invention

[0015] To address the aforementioned issues, this invention provides a system deterministic enhancement method. Targeting scenarios with extremely high real-time and deterministic requirements, such as industrial control, this method uses "critical CPUs / critical real-time tasks" as the core anchor point to transform the entire scheduler execution process into a "deterministic priority" approach. This eliminates the problems of uncontrollable time consumption, large latency jitter, and resource preemption in the original mechanism, ensuring the continuous, low-latency, and stable operation of critical real-time tasks.

[0016] This invention is implemented as follows:

[0017] A system determinism enhancement method addresses the uncertainties in six aspects during system program execution: interrupts, bottom half, scheduling, preemption, signal transmission, and protocol stack. It reduces the latency and jitter of critical real-time tasks through six means: core decision benchmark definition, kernel scheduling, interrupt handling, network protocol stack, signal handling, and container virtualization. Specifically, the core decision benchmark definition is implemented through step S1, kernel scheduling through step S2, interrupt handling through step S3, network protocol stack through step S4, signal handling through step S5, and container virtualization through step S6.

[0018] Step S1, core judgment benchmark definition: Define key CPUs and key real-time tasks, detect the readiness status of key CPUs and key real-time tasks, and trigger a periodic forced scheduling mechanism if they exist.

[0019] Step S2, Deterministic modification of the scheduler: trim unnecessary paths, simplify user-mode preemptive paths, and provide SMP forced scheduling mechanism and silent background threads;

[0020] Step S3, Real-time interrupt handling: Set critical interrupts to high priority, isolate critical CPUs and restrict the bottom half, and activate the periodic forced scheduling mechanism.

[0021] Step S4, Deterministic Modification of Protocol Stack: Optimize four aspects: NAPI polling, congestion fragmentation, Qdisc latency, and filtering rules to ensure real-time performance;

[0022] Step S5, Priority Signal Processing: Define the signal processed by the sender or receiver as a high-priority signal, and process high-priority signals first. Before processing low-priority signals, activate the periodic forced scheduling mechanism.

[0023] Step S6, Deterministic Container Modification: Remove CGroup restrictions, bind critical CPUs, disable NAT and port mapping, use native IO, and shut down non-core daemons.

[0024] The definition of the key CPU in step S1 includes the following steps:

[0025] Step S111: In kernel / sched / isolation.c, use the __setup function to add the rt_cpu processing function rt_cpu_setup, with the parameter rt_cpu_str;

[0026] Step S112: In kernel / sched / isolation.c, add a static cpumask_var_t variable named rt_cpu_mask;

[0027] Step S113: In the rt_cpu_setup processing function, analyze and process rt_cpu according to the isolcpus processing logic, and assign the processing result to rt_cpu_mask;

[0028] Step S114: Call housekeeping_isolcpus_setup() and pass the existing parameter rt_cpu_str to the processing function;

[0029] Step S115: Add the parameter rt_cpu=3 to the kernel boot parameters to enable the definition of critical CPUs;

[0030] Step S116: In kernel / sched / isolation.c, add the is_critical_cpu function, with the CPU ID as the parameter, i.e., cpu_id;

[0031] Step S117: In the is_critical_cpu function, determine whether the function parameter cpu_id is in rt_cpu_mask. If it is, return 1; otherwise, return 0.

[0032] The definition of the key real-time task in step S1 includes the following steps:

[0033] Step S121: In kernel / sched / core.c, add the is_critical_rt_task function with the task_struct structure as the parameter;

[0034] Step S122: Use rt_prio to determine if it is a FIFO or RR task. If it is, check if prio is less than or equal to 20. If it is, return 1; if either is not, return 0.

[0035] Step S123: Use dl_prio to determine if it is a DL task. If it is, return 1; otherwise, return 0.

[0036] The periodic forced scheduling mechanism in step S1 involves determining whether there are critical real-time tasks in the ready queue of the current CPU. If so, an IPI interrupt is sent to the corresponding CPU.

[0037] Specifically, the step S2 of pruning unnecessary paths includes the following steps:

[0038] Step S211: In the kernel / time / tick-common.c file, in the tick_handle_periodic() function, the rq_has_critical_task() function is used to determine whether there is a critical real-time task in the current CPU's ready queue. If there is, the tick_periodic() function in this function is adjusted to return directly after execution. If there is no critical real-time task, it is executed normally.

[0039] Step S212: In the kernel / shced / core.c file, the scheduler_tick() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, load balancing is not performed; otherwise, it is executed normally.

[0040] Step S213: In the kernel / time / timer.c file, the update_process_times() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU ready queue. If they exist, timeout handling and RCU pending tasks are not executed; otherwise, they are executed normally.

[0041] Specifically, step S2, which simplifies the user-mode preemption path, includes the following steps:

[0042] In the kernel / entry / common.c file, the exit_to_user_mode_loop() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, then uprobe, livepatch, signal handling, and notify are not executed; otherwise, they are executed.

[0043] The implementation of the SMP forced scheduling mechanism in step S2 specifically includes the following steps:

[0044] In include / linux / sched.h, the set_tsk_need_resched() function uses the rq_has_critical_task() function to determine whether there is a critical real-time task in the current CPU's ready queue. If it exists, the __schedule() function is executed immediately; otherwise, it is not executed.

[0045] In arch / arm64 / kernel / smp.c, the do_handle_IPI() function uses the is_critical_cpu() function to determine whether the current CPU is a critical CPU. If it is, the rq_has_critical_task() function is used to determine whether there is a critical real-time task in the current CPU's ready queue. If it exists, the __schedule() function is executed immediately. If it does not exist, the original code logic is maintained.

[0046] In the IPI_CALL_FUNC, IPI_TIMER, and IPI_IRQ_WORK processing logic, the rq_has_critical_task() function is used to determine whether the current CPU is a critical CPU. If it is, the original code logic is disabled; otherwise, it is executed normally.

[0047] In step S3, the restriction on the bottom half is as follows: if the current context is an interrupt context, the current CPU is in a critical CPU, the maximum execution frequency is limited, and there are critical real-time tasks in the ready queue of the current CPU, then the execution of soft interrupts is not allowed.

[0048] The Qdisc latency optimization in step S4 also includes skb request latency optimization.

[0049] Specifically, the filtering rule optimization in step S4 includes the following steps: developing a user-space filtering rule optimization tool, disabling the netfilter module and functions, and simplifying iptables rules.

[0050] The beneficial effects of this invention are:

[0051] The deterministic enhancement method of this invention, through the "deterministic priority" transformation of the entire link from kernel scheduling, interrupt handling, network protocol stack to container virtualization, reconstructs the general-purpose, throughput-priority operating system into an industrial control scenario-specific, deterministic priority architecture. This significantly reduces the latency and jitter of core paths such as critical task scheduling, interrupt response, and network packet sending and receiving, and greatly reduces problems such as uncontrollable time consumption, resource preemption, and virtualization amplification of latency in the native mechanism. The resource guarantee for critical real-time tasks within the container is close to that of a physical machine, ultimately enabling the Linux system to run with low latency and low jitter in critical real-time tasks in industrial control scenarios. Attached Figure Description

[0052] Figure 1 This is a schematic diagram illustrating the impact path of uncertainty on the entire process of system program execution in existing technologies;

[0053] Figure 2 This is a flowchart of the present invention. Detailed Implementation

[0054] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0055] This invention targets scenarios with extremely high requirements for real-time performance and determinism, such as industrial control. It takes "critical CPU / critical real-time task" as the core anchor point and transforms the entire execution process of the scheduler into a "deterministic priority" model. This eliminates problems such as uncontrollable time consumption, large latency jitter, and resource preemption in the original mechanism, ensuring the continuous, low-latency, and stable operation of critical real-time tasks.

[0056] Specifically, it can be broken down into the following core logic:

[0057] 1. First, clearly define the core judgment criteria as "critical CPUs" and "critical real-time tasks." All optimization strategies revolve around whether the current CPU's ready queue involves critical CPUs / critical real-time tasks as the core judgment condition, ensuring that optimization focuses only on core scenarios. Second, a deterministic fallback mechanism, namely a periodic forced scheduling mechanism, is implemented: a microsecond-level timer is set to detect the ready status of critical CPUs / critical real-time tasks. If they are present, periodic forced scheduling is triggered (sending IPI instructions) to ensure that critical tasks can preempt the CPU as soon as possible, compensating for delays in the preemption process.

[0058] 2. Scheduler: Eliminates unnecessary paths, strengthens preemption determinism, and provides a forced scheduling mechanism to avoid scheduling delays. Specifically, path pruning means that in the core scheduling function triggered by a clock interrupt, if a critical real-time task exists, unnecessary operations such as load balancing, local timer timeouts, and RCU processing are ignored, reducing the time consumption and uncertainty of a single interrupt; preemption optimization simplifies user-mode preemption paths, eliminating unnecessary logic such as uprobe and livepatch, accelerating preemption execution; the SMP forced scheduling mechanism directly triggers scheduling for critical CPUs / critical real-time tasks after setting the preemption flag or handling IPI interrupts, instead of two-stage preemption processing, avoiding the uncertainty of waiting for the scheduling point after readiness; and background thread silencing disables RCU threads and block device tasks on critical CPUs, eliminating resource preemption by background threads.

[0059] 3. Real-time Interrupts: Core interrupt response is ensured through a tiered, integrated isolation approach. First, NMI and preemptive interrupts are disabled, and an interrupt priority mechanism is provided, setting critical interrupts such as timers and network cards as high priority. Second, an affinity isolation mechanism is provided, isolating critical CPUs and scheduling irrelevant interrupts to non-critical CPUs, binding critical interrupts / processes to critical CPUs to reduce cross-core interference. Third, the bottom half needs to be restricted; that is, if critical real-time tasks are waiting to be scheduled on critical CPUs, the execution frequency of soft interrupts is limited, unnecessary soft interrupts are disabled, and execution time is compressed. Finally, when executing soft interrupts or the bottom half, a periodic forced scheduling mechanism needs to be activated to completely restrict the execution of uncontrollable bottom half tasks to one periodic forced scheduling cycle, significantly improving system determinism.

[0060] 4. Protocol Stack: Abandon throughput priority and focus on real-time requirements. First, improve the real-time performance of packet sending and receiving. (1) Provide configurable NAPI polling packet count / fixed interval query time and minimize the polling packet count and fixed interval query time to improve packet reception response speed; (2) Use pre-allocated memory pool for sending and receiving packets, and do not dynamically request memory to store data when sending or receiving packets; (3) Provide priority-based send buffer queues for multi-queue network cards to distinguish between business data and critical control data. Second, eliminate variable latency by using more efficient congestion algorithms, disabling TCP timestamps, and fixing the receive buffer to reduce latency jitter in protocol stack processing. Third, refine the load configuration by providing strategies for binding sockets, ports, and send queues, providing queue capabilities, and binding send queues to CPUs. Finally, if a firewall is introduced, disable unnecessary functions and eliminate advanced pattern matching rules to make rule traversal time controllable.

[0061] 5. Signal Processing: Ensuring Response to Critical Task Signals. First, prioritized signals must be provided. Signals processed by the sender or receiver are high-priority signals, while other tasks receive low-priority signals. During processing, high-priority signals are processed first to avoid queuing delays. Second, a periodic forced scheduling mechanism is needed before processing non-high-priority signals to prevent uncontrollable signal processing time.

[0062] 6. Container Layer: Eliminating the deterministic overhead of virtualization. Addressing the containerization needs of industrial control scenarios, this involves removing CGroup restrictions, binding critical CPUs, disabling NAT / port mapping (replacing it with macvlan), using native I / O, and shutting down non-core daemons. This ensures that critical real-time tasks within containers receive the same resource guarantees as native processes, avoiding the amplification of latency and jitter caused by virtualization.

[0063] 7. Overall logic summary: With "critical tasks not being disturbed, core paths being minimized, variable latency being eliminated, and resource priority being strengthened" as the core, the entire chain from kernel scheduling, interrupt handling, network protocol stack to container virtualization is transformed from "general-purpose, throughput-first" operating system to "scenario-based, deterministic-first" architecture, ultimately achieving highly reliable and low-jitter operation of critical real-time tasks in scenarios such as industrial control.

[0064] like Figure 2The diagram shows a flowchart of the system deterministic enhancement method of the present invention. The present invention addresses the uncertainties in six aspects during system program execution: interrupts, bottom halves, scheduling, preemption, signal transmission, and protocol stack. It reduces latency and jitter in critical real-time tasks through six means: core decision benchmark definition, kernel scheduling, interrupt handling, network protocol stack, signal processing, and container virtualization. Specifically, core decision benchmark definition is implemented in step S1, kernel scheduling in step S2, interrupt handling in step S3, network protocol stack implementation in step S4, signal processing in step S5, and container virtualization in step S6.

[0065] In this embodiment, a Linux system is used as an example to implement the above-mentioned overall inventive concept. A Phytium E2000Q device is used, and the corresponding kernel selected is the Phytium open-source kernel version 5.10, which can be obtained from Gitee. The specific steps include the following steps S1 to S6.

[0066] (1) Step S1, core judgment benchmark definition: Define key CPUs and key real-time tasks, detect the ready status of key CPUs and key real-time tasks, and trigger the periodic forced scheduling mechanism if they exist.

[0067] (11) The definition of the key CPU in step S1 includes the following steps:

[0068] Step S111: In kernel / sched / isolation.c, use the __setup function to add the rt_cpu processing function rt_cpu_setup, with the parameter rt_cpu_str;

[0069] Step S112: In kernel / sched / isolation.c, add a static cpumask_var_t variable named rt_cpu_mask;

[0070] Step S113: In the rt_cpu_setup processing function, analyze and process rt_cpu according to the isolcpus processing logic, and assign the processing result to rt_cpu_mask;

[0071] Step S114: At the end of the processing function, call housekeeping_isolcpus_setup() to pass the existing parameter rt_cpu_str to the processing function;

[0072] Step S115: Add the parameter rt_cpu=3 to the kernel boot parameters to enable the definition of critical CPUs;

[0073] Step S116: In kernel / sched / isolation.c, add the is_critical_cpu function, with the CPU ID as the parameter, i.e., cpu_id;

[0074] Step S117: In the is_critical_cpu function, determine whether the function parameter cpu_id is in rt_cpu_mask. If it is, return 1 (meaning that the given cpu_id is in the critical CPU). If it is not, return 0 (meaning that the given cpu_id is not in the critical CPU).

[0075] (12) The definition of the key real-time task in step S1 includes the following steps:

[0076] Step S121: In kernel / sched / core.c, add the is_critical_rt_task function with the task_struct structure as the parameter;

[0077] Step S122: Use rt_prio to determine if it is a FIFO or RR task. If it is, check if prio is less than or equal to 20. If it is, return 1; if either is not, return 0.

[0078] Step S123: Use dl_prio to determine if it is a DL task. If it is, return 1; otherwise, return 0.

[0079] (13) The periodic forced scheduling mechanism in step S1 is as follows: In the critical CPU, it is determined whether there is a critical real-time task in the ready queue of the current CPU. If there is, an IPI interrupt is sent to the corresponding CPU. Specifically, it includes the following steps:

[0080] Step S131: In kernel / sched / core.c, add the rq_has_critical_task() function to determine whether there is a critical task in the ready queue of the current CPU. That is, obtain the ready queues corresponding to all CPUs, traverse each scheduling entity in the ready queue, and call the is_critical_rt_task() function to determine whether it is a critical real-time task. If it is, return 1; if not, continue to traverse the remaining scheduling entities. If none of them are critical real-time tasks, return 0.

[0081] Step S132: In kernel / sched / core.c, add the periodic_force_sched_handler() function to determine whether the current CPU needs to send an IPI interrupt to the corresponding CPU. The specific function body is defined as follows: Iterate through all CPUs and call the rq_has_critical_task() function. If the return value is 1, use smp_send_reschedule() to send a rescheduling event to the corresponding CPU. If the return value is 0, do nothing.

[0082] Step S133: In kernel / sched / core.c, add the force_sched_timer_init() function, which creates a high-precision force_sched_hrtimer, handles timeouts as periodic_force_sched_handler, and starts the timer force_sched_hrtimer.

[0083] Step S134: In kernel / sched / core.c, add the force_sched_timer_exit() function and delete the force_sched_hrtimer timer.

[0084] (2) Step S2, scheduler deterministic modification: cut unnecessary paths, simplify user-mode preemptive paths, and provide SMP forced scheduling mechanism and silent background threads.

[0085] (21) Trim unnecessary paths

[0086] Each time a clock interrupt occurs, the scheduler executes the `tick_handle_periodic()` function. The core idea behind this adjustment is to handle only one `onshut` type timeout per interrupt; and to avoid performing other timeouts, RCU operations, or load balancing within a single interrupt. Specifically, this includes the following steps:

[0087] Step S211: In the kernel / time / tick-common.c file, in the tick_handle_periodic() function, the rq_has_critical_task() function is used to determine whether there is a critical real-time task in the current CPU's ready queue. If it exists, the tick_periodic() function inside this function is adjusted to return directly after execution. If it does not exist, it is executed normally.

[0088] Step S212: In the kernel / shced / core.c file, the scheduler_tick() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, load balancing is not performed; otherwise, it is executed normally.

[0089] Step S213: In the kernel / time / timer.c file, the update_process_times() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, the run_local_timers() and rcu_sched_clock_irq() functions are not executed, that is, the local timer timeout handling and RCU pending tasks are not executed. If they do not exist, they are executed normally.

[0090] (22) Simplify the user-mode preemption path

[0091] Preemption is divided into user-mode preemption, which occurs upon returning from a system call (primarily executed by the function `exit_to_user_mode_prepare`) and upon returning to user mode from an interrupt (primarily executed by the function `exit_to_user_mode_prepare`). Kernel-mode preemption occurs upon returning to kernel mode from an interrupt (primarily executed by the function `preempt_enable`) and when preemption is enabled (primarily executed by the function `preempt_schedule_irq`). In the `exit_to_user_mode_prepare()` function, before returning to user mode, unpredictable timing processes such as uprobe, livepatch, signals, and notify are executed. In the `preempt_enable()` and `preempt_schedule_irq()` functions, the `__schedule()` function is directly called without optimization.

[0092] Specifically, it includes the following steps:

[0093] In the kernel / entry / common.c file, the exit_to_user_mode_loop() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, then uprobe, livepatch, signal handling, and notify are not executed; otherwise, they are executed.

[0094] (23) SMP forced scheduling mechanism

[0095] As mentioned above, preemption involves two steps: first, setting the TIF_NEED_RESCHED flag; and second, performing the preemption operation after waiting for a certain period. This step-by-step execution means that some critical real-time tasks, once ready, cannot immediately preempt the CPU. Therefore, a forced scheduling mechanism is needed to force the CPU into a preemptive state after setting the TIF_NEED_RESCHED flag. Furthermore, multi-core processors need to be considered, requiring forced preemption during the IPI processing flow. Therefore, the implementation of the SMP forced scheduling mechanism in step S2 includes the following steps:

[0096] Step S231: In include / linux / sched.h, the set_tsk_need_resched() function uses the rq_has_critical_task() function to determine whether there is a critical real-time task in the current CPU's ready queue. If it exists, the __schedule() function is executed immediately; otherwise, it is not executed.

[0097] Step S232: In `arch / arm64 / kernel / smp.c`, within the `do_handle_IPI()` function, in the `IPI_RESCHEDULE` processing logic, the `is_critical_cpu()` function is used to determine if the current CPU is a critical CPU. If it is, the following operations are performed: The `rq_has_critical_task()` function is used to check if there are any critical real-time tasks in the current CPU's ready queue. If they exist, the `__schedule()` function is executed immediately; otherwise, the original code logic is maintained. If it is not a critical CPU, the original code logic is disabled. In the `IPI_CALL_FUNC`, `IPI_TIMER`, and `IPI_IRQ_WORK` processing logic, the `rq_has_critical_task()` function is used to determine if the current CPU is a critical CPU. If it is, the original code logic is disabled; otherwise, normal execution occurs.

[0098] (24) Silent background threads

[0099] The Linux kernel provides several threads for each CPU, such as CPU hot-plugging (cpuhp), idle injection (idle_inject), process migration (migration), soft interrupt daemon (ksoftirqd), block device handling (kworker), and RCU handling (rcu). While these mechanisms can increase the resource utilization of the Linux system, they are disastrous for scenarios that prioritize real-time and deterministic operations, severely impacting system predictability. The cpuhp, idle_inject, and migration threads can be silenced through CPU isolation, but the block device handling and RCU handling threads cannot be silenced and require special handling. The specific adjustment scheme is as follows:

[0100] Step S241: In kernel / rcu / tree.c, within the rcu_init() function, before creating an RCU thread for each CPU, it checks whether the ID of the CPU to be created is within the critical CPU. If it is, the RCU thread is not created; otherwise, the RCU thread is created.

[0101] Step S242: In kernel / rcu / tree.c, add a judgment to the rcu_cpu_kthread_should_run() function, and use the rq_has_critical_task() function to determine whether the current CPU is in the critical CPU. If it is, return 0; otherwise, continue to execute the original code logic.

[0102] Step S243: In block / blk-core.c, within the kblockd_schedule_work() function, replace queue_work with queue_work_on and specify the CPU as a non-critical CPU.

[0103] (3) Step S3, real-time interrupt handling: set critical interrupts to high priority, isolate critical CPUs and restrict the bottom half, and activate the periodic forced scheduling mechanism.

[0104] (31) Interrupt priority implementation

[0105] Linux systems do not have the concept of interrupt priority. To ensure that more important interrupts are handled first, interrupts of specific priorities need to be specially processed, i.e., their priority needs to be increased. The specific adjustment scheme for setting critical interrupts to high priority is as follows:

[0106] Step S311: Add the declaration of the function set_gic_irq_prior() in include / linux / irq.h. The first parameter is the interrupt sequence number, i.e., intnr, and the second parameter is the interrupt priority, i.e., prior. The default is medium (GIC_IRQ_NORMAL), and it can be set to high (GIC_IRQ_HIGH) and low (GIC_IRQ_LOW).

[0107] Step S312: Add the set_gic_irq_prior() function body to kernel / irq / chip.c. The specific function is as follows: First, use the irq_to_desc() function to convert intnr to irq_desc, and obtain the irq_data structure of irq_desc. The gic_irq() function obtains the hardware interrupt number hwirq corresponding to intnr. Use gic_dist_base() to obtain the base address of GIC, i.e. gic_base. Obtain the priority address corresponding to hwirq in this way according to the chip manual: gic_dist_base(data) + GIC_DIST_PRI + (hwirq / 4) * 4, i.e., prior_addr. Then, use the writel_relaxed() function to write the prior parameter to the address prior_addr.

[0108] Step S313: Add the proc_set_irq_prior() function body to kernel / irq / chip.c. First, create the / proc / irq / set_prior file, input the interrupt sequence number and interrupt priority, and then call the set_gic_irq_prior() function to set the interrupt priority.

[0109] Step S314: Set the interrupt number corresponding to the timer and network card to high priority via / proc / irq / set_prior.

[0110] (32) Restriction of the bottom half

[0111] To improve interrupt response speed and reduce the impact of interrupts on the system, Linux systems divide interrupts into a top half and a bottom half. The top half disables interrupts and preemption, executes quickly, and then exits, leaving the remaining complex tasks to the bottom half. The bottom half has multiple types; in the 5.10 kernel, there are 10 types: high / low priority tasklets, timers, network transceivers, block devices, polling, schedulers, high-precision clocks, and RCU. Each execution can last up to 2ms, and the timing of interrupts and preemption is highly unpredictable, making this a critical area of ​​deterministic behavior that requires strict control. Therefore, step S3 restricts the bottom half: if the current context is an interrupt context, and the current CPU is on a critical CPU, the maximum execution frequency is limited to once; and if there are critical real-time tasks in the current CPU's ready queue, then soft interrupts are not allowed.

[0112] Specifically, in kernel / softirq.c, in the __do_softirq() function, if the current context is an interrupt context (determined using the in_irq function) and the current CPU is within a critical CPU, the maximum execution frequency is limited to 1 time (configurable).

[0113] If the current context is an interrupt context (determined using the in_irq function), the current CPU is in a critical CPU, and there is a critical real-time task in the current CPU's ready queue (determined using the rq_has_critical_task() function), then soft interrupts are not allowed to be executed.

[0114] Before processing the handler corresponding to the bottom half, activate the periodic forced scheduling mechanism.

[0115] (33) Realization of scenario-based affinity

[0116] Application CPU interrupts, service-dependent peripheral interrupts, and other irrelevant interrupts all affect the real-time performance of the application. Interrupt handlers often have high priority, and neglecting to handle them can cause serious problems. Therefore, both real-time performance and interrupt response need to be addressed as quickly as possible. This requires separating the service-running CPU from irrelevant interrupts, and keeping the service-running CPU and service-dependent peripherals on the same CPU as much as possible. To this end, step S3 also includes scenario-based affinity implementation, with the specific adjustments as follows:

[0117] Step S331: Modify the kernel boot parameters by adding the parameter isolcpus=3, which is the same as the rt_cpu parameter value, to ensure that no application exists on the critical CPU.

[0118] Step S332: Add the function body proc_set_irq_task_affi() to kernel / irq / chip.c. The first parameter is an interrupt sequence number array, i.e., intnr[], and the second parameter is a process pid array, i.e., pidnr[]. The function executes the following logic: adjust all interrupts in the system except timers to non-critical CPUs by setting affinity; adjust each interrupt in the intnr[] array to the critical CPU by setting affinity; adjust each process in the pidnr[] array to the critical CPU by setting affinity.

[0119] (4) Step S4, Deterministic modification of the protocol stack: Optimize from four aspects: NAPI polling, congestion fragmentation, Qdisc delay and filtering rules to ensure real-time performance.

[0120] (41) NAPI polling optimization

[0121] Early Linux systems generated an interrupt upon receiving network data packets. If a large number of software packages arrived simultaneously, it would severely impact the normal operation of the device. To address this, the NAPI mechanism was introduced, which improves throughput and reduces the number of interrupts. However, in industrial control scenarios, real-time performance is more important than throughput. To improve real-time performance, the following adjustments were made:

[0122] A user-space NAPI optimization tool, napi_tunning_tools, was developed to bind network card interrupts to critical CPUs through affinity settings, reduce the maximum number of packets per polling cycle from the default value of 300 to 16, and shorten the polling timeout from the default value of 2000 microseconds to 100 microseconds.

[0123] (42) Congestion fragmentation optimization

[0124] The TCP SACK mechanism incurs variable overhead at the receiver, with both the O(n) level SACK block list maintenance overhead and the additional overhead of TCP option encapsulation. The overhead is extremely low when there is no out-of-order delivery, but increases significantly with out-of-order delivery, directly lengthening the single-packet processing link. This causes packet latency jitter to rise from the 10μs level to the 100μs level. In the complex, highly out-of-order network environment of industrial control, the SACK block list expands rapidly, leading to an exponential increase in receiver traversal and assembly overhead, a surge in CPU utilization, and squeezing CPU resources for real-time tasks, resulting in real-time task response delays. The TCP timestamp mechanism adds 1-10 microseconds of time consumption at the sender and 10-20 microseconds at the receiver, with non-fixed and highly fluctuating latency, having a certain uncontrollable impact on network packet transmission and reception in industrial control scenarios. Furthermore, the automatic adjustment of the receive buffer causes dynamic fluctuations in the buffer size and receive window (RWND) during actual operation, resulting in uncontrollable single-packet dwell time and latency jitter. The specific optimization measures are as follows: Develop a user-space congestion fragmentation optimization tool, jam_tunning_tools, replace the default congestion control algorithm cubic with reno, disable the TCP timestamp mechanism, and fix the receive buffer size to avoid dynamic adjustments.

[0125] (43) Qdisc latency optimization

[0126] When an application sends data, it dynamically requests an skb and puts it into a Qdisc queue for Qdisc to send. This seemingly simple process has significant uncertainties. For example, requesting an skb may cause the application to sleep, which could lead to the real-time process being swapped out. There are various Qdisc sending mechanisms, but Linux systems usually use CFQ to ensure throughput. In real-time control scenarios, this scheduling mechanism can cause critical control data to be affected by business data, thus increasing uncertainty.

[0127] Linux systems typically use CFQ scheduling to improve network throughput, but industrial control scenarios prioritize real-time performance. While no-loop is the optimal choice for lower transmission latency, industrial control scenarios involve a mix of non-real-time business data and actual control data transmission, requiring a balance between real-time performance and throughput.

[0128] Optimization techniques include skb allocation latency optimization and Qdisc latency optimization, as detailed below:

[0129] The optimization of skb request latency includes the following steps:

[0130] Adjust the kernel configuration, setting CONFIG_SKBUFF_FCLONE, CONFIG_NET_RX_BUF_POOL, and CONFIG_NETDEV_ALLOC_FROM_POOL to Y;

[0131] Develop a user-space skb cache hit rate optimization tool, namely skb_cache_tunning_tools;

[0132] Set the minimum number of pages to be pre-allocated for skbuff_head_cache to 1024;

[0133] Set the minimum number of pages to be pre-allocated for skbuff_fclone_cache to 2048;

[0134] The size of the pre-allocated skb pool is fixed and dynamic adjustment is prohibited.

[0135] Pre-allocated pools are used to bind network interface cards (NICs) to queues on critical CPUs;

[0136] For critical real-time tasks (such as the vPLC protocol stack), execute mlockall(MCL_CURRENT|MCL_FUTURE) to lock the process memory and skb buffer.

[0137] The Qdisc latency optimization specifically includes the following steps:

[0138] Develop a user-space qdisc optimization tool, namely qdisc_tunning_tools;

[0139] Adjust the network card scheduling method to pfifo_fast;

[0140] Set the sending port 8080 corresponding to the critical real-time task to high-priority traffic;

[0141] Set the receiving port 8080 corresponding to the critical real-time task to high-priority traffic.

[0142] (44) Filtering rule optimization

[0143] The netfilter / iptables mechanism introduces variable latency for packet traversal of rule chains, preemption conflicts at kernel-mode hook points, and dynamic overhead for connection tracking (conntrack), leading to amplified latency jitter in single-packet processing (processing time < 1 μs for no rules, ≈ 5 μs for 10 ordinary rules, and ≈ 50 μs for 100 rules; furthermore, the latency jitter increases from μs to ms due to the "whether a rule is hit" and "which rule is hit" criteria). In real-time control scenarios, the core principles of "minimum rule set + disabling unnecessary functions + CPU isolation" must be followed to reduce iptables overhead to a predictable, fixed value, prioritizing determinism over functional completeness. Filtering rule optimization includes the following steps: developing a user-mode filtering rule optimization tool, disabling netfilter modules and functions, and simplifying iptables rules.

[0144] The specific measures are as follows: Develop a user-space filtering rule optimization tool, namely fetfilter_tunning_tools, disable netfilter modules and functions, including conntrack, log / counting operations, and NAT, simplify iptables rules, use only IP / port / protocol matching, and disable complex matching, such as merging multiple rules with -s192.168.1.0 / 24 into one rule using the -m conntrack parameter.

[0145] (5) Step S5, priority signal processing: Define the signal processed by the sender or receiver as a high priority signal, and process the high priority signal first. Before processing the low priority signal, activate the periodic forced scheduling mechanism.

[0146] Linux signal handling is sequential, and the timing of signal processing is unpredictable. There might be real-time tasks whose signals urgently need processing, but previous signals are still in the queue, preventing the real-time tasks from executing on time. Therefore, signals sent or received by real-time tasks need to be processed with high priority. In addition, a periodic forced scheduling mechanism needs to be activated before processing low-priority signals to prevent unpredictable signal processing times. The adjustment plan is as follows:

[0147] (51) Signal structure adjustment

[0148] In the include / linux / signal_types.h file, add #define SIGQUEUE_PREALLOC 1 below #define SIGQUEUE_PREALLOC 1 to indicate that the signal is sent by a real-time task or is a signal sent to a real-time task.

[0149] (52) Adjustment of sending logic

[0150] In the __send_signal() function of the kernel / signal.c file, if the task currently sending the signal is a critical real-time task, or if the task receiving the signal is a critical real-time task, then set the flags corresponding to the sent signal to |= SIGQUEUE_RT.

[0151] (53) Processing logic adjustment

[0152] At the entry point of the next_signal() function in the kernel / signal.c file, the function parameter pending->list (this linked list is the structure of the signals to be processed) is traversed. When the flags of an element in this linked list are set to SIGQUEUE_RT, the signal is returned. If none of the elements are set to SIGQUEUE_RT after traversal, the original logic of next_signal is executed. In the get_signal() function, the periodic forced scheduling mechanism is activated.

[0153] (6) Step S6, container deterministic modification: remove CGroup restrictions, bind critical CPUs, disable NAT and port mapping, use native IO and shut down non-core daemons.

[0154] The container's CGroups mechanism may cause deterministic loss; container network virtualization amplifies transmission latency and jitter; containerd-shim threads share the CPU with real-time tasks within the container, leading to increased response latency for real-time tasks. To improve the real-time performance of applications within containers, the following measures are recommended:

[0155] Step S61: Write the user-space container optimization daemon, namely container_daemon_tunning_tools;

[0156] Step S62: Remove the container's CGroup limit (--cpu-period=100000 --cpu-quota=-1);

[0157] Step S63: Bind the container to the critical CPU (--cpuset-cpus=1).

[0158] Step S64: Set the process running inside the container as a critical real-time task;

[0159] Step S65: Use native IO devices, disable the container image layer, and eliminate image layer mounting overhead and IO scheduling overhead (--volume / dev / sda1: / data --storage-driver=devicemapper).

[0160] Step S66: Disable port mapping and NAT mechanism;

[0161] Step S67: Introduce macvlan technology to replace container bridging;

[0162] Step S68: Disable non-core functions of the container daemon (such as logging and monitoring) to reduce runtime resource consumption.

[0163] This invention takes "critical CPUs / critical real-time tasks" as its core anchor point. First, it clarifies the core judgment criteria: critical CPUs are defined by the CPU ID specified by the kernel startup parameter `rt_cpu`, and critical real-time tasks are tasks on critical CPUs with scheduling types of FIFO / RR (priority greater than 80) or DL. All optimization strategies use whether the current CPU ready queue involves critical CPUs / critical real-time tasks as the core judgment condition. Based on this, and adhering to the core principles of "critical tasks not being disturbed, core paths being minimized, variable latency being eliminated, and resource priority being strengthened," it implements precise protection across the entire chain: At the scheduler level, unnecessary paths in the clock interrupt core function are trimmed (load balancing, local timer timeouts, RCU processing, etc. are masked), user-mode preemption logic is simplified (unnecessary processes such as uprobe and livepatch are disabled), a forced scheduling mechanism is added (setting a preemption flag / directly triggering scheduling when handling IPI interrupts), and the RCU thread and block device processing thread of critical CPUs are silenced. At the real-time interrupt level, high priority is set for critical interrupts such as timers and network cards, and irrelevant interrupts are scheduled to non-critical CPUs through affinity isolation (critical interrupt / process binding). At the critical CPU level, the frequency and duration of execution of the bottom half / soft interrupts of critical CPUs are limited, and periodic forced scheduling is added. At the protocol stack level, NAPI polling parameters are optimized (reducing the number of packets per polling and shortening the timeout time), pre-allocating skb memory pools to eliminate dynamic allocation time, replacing congestion algorithms / disabling TCP timestamps / fixing receive buffers to eliminate variable latency, fine-tuning RSS hash / queue binding and Qdisc scheduling rules, simplifying netfilter / iptables rules and disabling unnecessary functions. At the signal processing level, dedicated identifiers are added to signals of critical real-time tasks and they are given priority, while signal processing function timeouts are limited. At the container layer level, CGroup restrictions are removed, critical CPUs are bound, NAT / port mapping is disabled (and replaced with macvlan), native IO is used, and non-core daemons are shut down to eliminate deterministic losses caused by virtualization. Ultimately, the focus is on core scenarios to systematically and significantly improve the problems of uncontrollable latency, large latency jitter, and resource preemption in the native mechanism.

[0164] This invention reconstructs a general-purpose, throughput-first operating system into an industrial control-specific, deterministic-first architecture by modifying the entire chain from kernel scheduling, interrupt handling, network protocol stack to container virtualization to a "deterministic-first" approach. This significantly reduces latency and jitter in core paths such as critical task scheduling, interrupt response, and network packet transmission and reception, and greatly reduces problems such as uncontrollable time consumption, resource preemption, and virtualization amplification of latency in the native mechanism. The resource guarantee for critical real-time tasks within the container is close to that of a physical machine, ultimately enabling the Linux system to run with low latency and low jitter in critical real-time tasks in industrial control scenarios.

[0165] While the present invention discloses preferred embodiments to achieve the above objectives, these are not intended to limit the structural features of the invention. Anyone skilled in the art should know that any easily conceived variations or modifications are possible within the technical spirit of the invention and are covered by the claims of the present invention.

Claims

1. A method for enhancing the determinism of a system, characterized in that, To address the uncertainties in six aspects during system program execution—interrupts, bottom half, scheduling, preemption, signal transmission, and protocol stack—six methods are employed to reduce latency and jitter in critical real-time tasks: core judgment benchmark definition, kernel scheduling, interrupt handling, network protocol stack, signal handling, and container virtualization. Specifically, core judgment benchmark definition is implemented through step S1, kernel scheduling through step S2, interrupt handling through step S3, network protocol stack through step S4, signal handling through step S5, and container virtualization through step S6. Step S1, core judgment benchmark definition: Define key CPUs and key real-time tasks, detect the readiness status of key CPUs and key real-time tasks, and trigger a periodic forced scheduling mechanism if they exist. Step S2, Deterministic Modification of the Scheduler: Eliminating unnecessary paths, simplifying user-mode preemptive paths, and providing an SMP forced scheduling mechanism and silent background threads. The implementation of the SMP forced scheduling mechanism specifically includes the following steps: In include / linux / sched.h, the set_tsk_need_resched() function uses the rq_has_critical_task() function to determine whether there is a critical real-time task in the current CPU's ready queue. If it exists, the __schedule() function is executed immediately; otherwise, it is not executed. In arch / arm64 / kernel / smp.c, the do_handle_IPI() function uses the is_critical_cpu() function to determine whether the current CPU is a critical CPU. If it is, the rq_has_critical_task() function is used to determine whether there is a critical real-time task in the current CPU's ready queue. If it exists, the __schedule() function is executed immediately. If it does not exist, the original code logic is maintained. In the processing logic of IPI_CALL_FUNC, IPI_TIMER, and IPI_IRQ_WORK, the rq_has_critical_task() function is used to determine whether the current CPU is a critical CPU. If it is, the original code logic is disabled; otherwise, it is executed normally. Step S3, Real-time interrupt handling: Set critical interrupts to high priority, isolate critical CPUs and restrict the bottom half, and activate the periodic forced scheduling mechanism. Step S4, Deterministic Modification of Protocol Stack: Optimize four aspects: NAPI polling, congestion fragmentation, Qdisc latency, and filtering rules to ensure real-time performance; Step S5, Priority Signal Processing: Define the signal processed by the sender or receiver as a high-priority signal, and process high-priority signals first. Before processing low-priority signals, activate the periodic forced scheduling mechanism. Step S6, Deterministic Container Modification: Remove CGroup restrictions, bind critical CPUs, disable NAT and port mapping, use native IO, and shut down non-core daemons.

2. The system determinism enhancement method according to claim 1, characterized in that, The definition of the key CPU in step S1 includes the following steps: Step S111: In kernel / sched / isolation.c, use the __setup function to add the rt_cpu processing function rt_cpu_setup, with the parameter rt_cpu_str; Step S112: In kernel / sched / isolation.c, add a static cpumask_var_t variable named rt_cpu_mask; Step S113: In the rt_cpu_setup processing function, analyze and process rt_cpu according to the isolcpus processing logic, and assign the processing result to rt_cpu_mask; Step S114: Call housekeeping_isolcpus_setup() and pass the existing parameter rt_cpu_str to the processing function; Step S115: Add the parameter rt_cpu=3 to the kernel boot parameters to enable the definition of critical CPUs; Step S116: In kernel / sched / isolation.c, add the is_critical_cpu function, with the CPU ID as the parameter, i.e., cpu_id; Step S117: In the is_critical_cpu function, determine whether the function parameter cpu_id is in rt_cpu_mask. If it is, return 1; otherwise, return 0.

3. The system determinism enhancement method according to claim 2, characterized in that, The definition of the key real-time task in step S1 includes the following steps: Step S121: In kernel / sched / core.c, add the is_critical_rt_task function with the task_struct structure as the parameter; Step S122: Use rt_prio to determine if it is a FIFO or RR task. If it is, check if prio is less than or equal to 20. If it is, return 1; if either is not, return 0. Step S123: Use dl_prio to determine if it is a DL task. If it is, return 1; otherwise, return 0.

4. The system determinism enhancement method according to claim 3, characterized in that, The periodic forced scheduling mechanism in step S1 is as follows: in the critical CPU, it is determined whether there is a critical real-time task in the ready queue of the current CPU. If there is, an IPI interrupt is sent to the corresponding CPU.

5. The system determinism enhancement method according to claim 1, characterized in that, The step of trimming unnecessary paths in step S2 specifically includes the following steps: Step S211: In the kernel / time / tick-common.c file, in the tick_handle_periodic() function, the rq_has_critical_task() function is used to determine whether there is a critical real-time task in the current CPU's ready queue. If there is, the tick_periodic() function in this function is adjusted to return directly after execution. If there is no critical real-time task, it is executed normally. Step S212: In the kernel / shced / core.c file, the scheduler_tick() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, load balancing is not performed; otherwise, it is executed normally. Step S213: In the kernel / time / timer.c file, the update_process_times() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU ready queue. If they exist, timeout handling and RCU pending tasks are not executed; otherwise, they are executed normally.

6. The system determinism enhancement method according to claim 5, characterized in that, The step S2, which simplifies the user-mode preemption path, specifically includes the following steps: In the kernel / entry / common.c file, the exit_to_user_mode_loop() function uses the rq_has_critical_task() function to determine whether there are critical real-time tasks in the current CPU's ready queue. If they exist, then uprobe, livepatch, signal handling, and notify are not executed; otherwise, they are executed.

7. The system determinism enhancement method according to claim 1, characterized in that, The restriction on the bottom half in step S3 is as follows: if the current context is an interrupt context, the current CPU is in a critical CPU, the maximum execution frequency is limited, and there are critical real-time tasks in the ready queue of the current CPU, then the execution of soft interrupts is not allowed.

8. The system determinism enhancement method according to claim 1, characterized in that, The Qdisc latency optimization in step S4 also includes skb request latency optimization.

9. The system determinism enhancement method according to claim 8, characterized in that, The filtering rule optimization in step S4 specifically includes the following steps: developing a user-space filtering rule optimization tool, disabling the netfilter module and functions, and simplifying iptables rules.

Images