A method for improving real-time performance of a Linux operating system application based on a multi-core CPU

Abstract

This invention provides a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU. The method includes, during system startup, modifying Linux kernel startup parameters to reallocate tasks across the cores of the multi-core CPU, concentrating basic Linux system tasks on the zeroth core; when the target application creates a task, it sets task affinity based on the task's real-time requirements by calling system functions; non-real-time critical tasks are assigned to the first core; real-time critical tasks are assigned to the second core; and sub-real-time critical tasks are assigned to the third core. This invention effectively reduces the response latency of specific interrupts with strict real-time requirements in the Linux system by utilizing different cores of a multi-core CPU to allocate different tasks, improving device real-time performance and meeting the real-time requirements of fields such as power distribution automation.

Description

Technical Field

[0001] This invention relates to the fields of power distribution network automation control and computer operating system technology, specifically to a method for improving the real-time performance of Linux operating system applications based on multi-core CPUs. By optimizing the task allocation and scheduling strategy of multi-core CPUs and combining it with customized configuration of the Linux kernel, the method solves the problem of insufficient real-time performance of traditional Linux systems in industrial control scenarios, and is particularly suitable for fields sensitive to deterministic latency such as power distribution network automation, smart grids, and industrial Internet of Things. Background Technology

[0002] The standard Linux operating system, designed to maximize throughput and fairness, exhibits significant latency jitter when handling hardware interrupts, typically on the order of milliseconds. However, power distribution automation applications have stringent requirements for hardware interrupt response times, demanding a minimum interrupt response latency of less than 10 microseconds. Therefore, standard Linux systems cannot meet the demands of industrial control scenarios with extremely high real-time requirements, such as power distribution automation.

[0003] The existing technology has the following drawbacks: Typical Linux systems use the CFS scheduler, which emphasizes fairness rather than real-time performance, resulting in interrupt response latency reaching hundreds of microseconds or even milliseconds under heavy load. Furthermore, it suffers from the following real-time limitations: Kernel non-preemption: Traditional Linux kernels cannot be preempted by high-priority tasks when executing system calls or interrupt handling, resulting in unpredictable critical path delays.

[0004] Interrupt masking causes response delays: Kernel critical sections block timely responses to high-priority hardware interrupts by disabling interrupts.

[0005] Spinlock blocking preemption: There are a large number of spinlocks in the kernel, and preemption is prohibited during the holding period, resulting in an uncontrollable delay window.

[0006] Scheduler design is nondeterministic: The CFS scheduler lacks strict priority guarantees for hard real-time tasks.

[0007] Priority inversion problem: High-priority tasks may be blocked while waiting for resources held by low-priority tasks.

[0008] Memory allocation blocking: Memory allocation may trigger page faults, resulting in unpredictable long delays.

[0009] Coarse clock granularity: The default clock frequency results in an excessively long scheduling cycle, which cannot meet the microsecond-level response requirements.

[0010] Lack of priority inheritance and deadlock prevention mechanisms: The standard kernel does not have built-in automatic handling of priority inversion.

[0011] However, although a combination of configurations such as PREEMPT_RT, interrupt affinity, CPU isolation, and memory locking can improve real-time performance to some extent, it still cannot meet the application scenarios with extreme real-time requirements, such as distribution network automation. Summary of the Invention

[0012] This invention provides a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU. By utilizing different cores of a multi-core CPU to allocate different tasks, the response latency of specific interrupts with strict real-time requirements in the Linux system is effectively reduced, thereby improving the real-time performance of the device and meeting the real-time requirements of fields such as power distribution automation.

[0013] The present invention achieves the above objectives through the following technical solutions: A method for improving the real-time performance of Linux operating system applications based on multi-core CPUs includes: During the system startup phase, by modifying the startup parameters of the Linux kernel, the core tasks of each core in the multi-core CPU are redistributed, and the basic running tasks of the Linux system are concentrated and distributed to run on the zeroth core. After the Linux kernel has finished booting and successfully loaded the root file system, the kernel driver module is loaded using a preset command to start the target application. When the target application creates a task, it sets the task affinity by calling system functions according to the task's real-time requirements. Assign non-real-time critical tasks to run on the first core; Real-time critical tasks are assigned to the second core for execution. By configuring the interrupt priority on the second core to the highest level and enabling the kernel's interrupt preemptive mode, high-priority interrupts interrupt the processing of low-priority interrupts. At the same time, the corresponding system function is called through the interrupt number to request the first interrupt handling interface and set the first interrupt affinity. The secondary real-time critical task is assigned to run on the third core. The secondary real-time critical task is also configured to interrupt mode, and the interrupt priority on the third core is set to the second highest level, second only to the interrupt priority of the real-time critical task. The system function is called through the interrupt number to request the second interrupt handling interface, and the second interrupt affinity is set.

[0014] According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided. During the BootLoader's loading of the Linux kernel, the boot parameters `bootargs` are modified, and parameter configurations are added to achieve the reallocation of core tasks. Specific parameter configurations include: Use isolcpus=<cpu_list1> Parameter isolation is used to isolate other kernels besides the core that runs the basic tasks of the Linux system.<cpu_list1> This is a list of core IDs to be isolated, configured as isolcpus=1-3; Use nohz_full=<cpu_list2> The parameter configuration specifies a completely clockless tick mode, where<cpu_list2> The core number list that is configured to have no clock tick, i.e., configured as nohz_full=1-3; Use rcu_nocbs=<cpu_list3> The parameter prevents the RCU mechanism from triggering callback functions on the specified core, where<cpu_list3> This is a list of core numbers where RCU callbacks are disabled, configured as rcu_nocbs=1-3.

[0015] According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided, which allocates non-real-time critical tasks to the first core for execution, including: Define the set of non-real-time critical tasks as T nonreal Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, of which c 1 is the primary core; Set function Φ1 through CPU affinity. T , C This will aggregate non-real-time critical tasks. T nonreal Bind to the first core c 1. Run the application and establish an exclusive or shared runtime environment that satisfies the following mapping relationship: 1 t ∈ T nonreal , Φ1( t )={ c 1}; Wherein, Φ1( t ) indicates a task t The set of CPUs allowed to run. t It is a set of non-real-time critical tasks T nonreal Any one of the tasks in, 1 is a universal quantifier. 1 t This means for all members Tnonreal Task t ; Define the core load function L ( c i ) indicates the core c i The task load on the platform, through affinity binding, forces the following isolation constraints to be met: L ( c 1)∩ L ( c 2)= ∧ L ( c 1)∩ L ( c 3)= ; in, L ( c 1) L ( c 2) and L ( c 3) respectively in its core c 1. c 2 and c Task load on 3 It is an empty set; During the system startup phase, the basic daemons and user-space non-real-time applications of the Linux system are migrated to the first kernel via kernel boot parameters or initialization scripts. c 1. Run; Using the CPU mask operation function Ψ cpu ( mask1 , c id Generate the first core c Mask of 1: mask 1=Ψ cpu (0,1); and the first core c A mask of 1 is applied to the creation interface for all non-real-time critical tasks.

[0016] According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided, which allocates real-time critical tasks to run on a second core, including: Define the set of real-time critical tasks as T real Let the system's physical CPU core set be... C ={ c 0, c 1, c 2,c 3}, the set of real-time critical tasks is set through the CPU affinity setting function Φ2. T real Bind to the second core c 2. Establish a dedicated runtime environment that satisfies the following mapping relationships: 2 t ∈ T real ,Φ2( t )={ c 2}; Wherein, Φ2( t ) indicates a task t The set of CPUs allowed to run, and this set contains only the second core. c 2, t It is a set of real-time critical tasks. T real Any one of the tasks in, 2 is a universal quantifier. 2 t This means for all members T real Task t .

[0017] According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided, which defines an interrupt priority function. P 1( I n ),in I n For the first n One interrupt source, for allocation to the second core c 2 Real-time critical task interruption I real Configure its priority to the highest level in the system. P max ,Right now: P ( I real )= P min_val ; in, P min_val This represents the minimum value among the system priority values; Configure kernel preemption mode parameters K preempt In a preemptible state, under kernel preemptive mode, when the second core... c 2. A low-priority interrupt service routine is being executed. ISR low If a real-time critical task is interruptedI real Triggered when the following preemption conditions are met: P ( I real )< P ( ISR low )∧ K preempt =1 Execute ( I real ) Execute ( ISR low ); in, Execute ( I real This indicates that the execution of a real-time critical task was interrupted. I real , Execute ( ISR low This indicates that a low-priority interrupt service routine will be executed. ISR low ,symbol This refers to the preemptive / priority execution logic, specifically the interruption of high-priority real-time critical tasks. I real The execution immediately preempts the current low-priority interrupt service routine. ISR low The execution context; Through system call interface Request _ IRQ ( I num , Handler , Flags ) Request real-time critical mission interruption I real The first interrupt handling interface, in which I num This is the interruption number. Handler Pointer to an interrupt service routine; At the same time, the interrupt affinity setting function Ψ( I num , C mask1 ),Will I real Target processing core mask C mask1 Configured to include only the second core c 2. The formula is expressed as: Ψ( I num ,C mask1 → C mask1 ={ c 2}; According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided, which allocates sub-real-time critical tasks to a third core for execution, including: Define the set of sub-real-time critical tasks as T sub Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, through the CPU affinity mapping function Φ3( T , c This will create a set of sub-real-time critical tasks. T sub Binding to the third core c 3. Establish a dedicated runtime environment that satisfies the following mapping relationships: 3 t ∈ T sub ,Φ3( t )={ c 3}; Among them, Φ3( t ) indicates a task t The set of CPUs allowed to run. t This is a set of real-time critical tasks. T sub Any one of the tasks in, 3 is a universal quantifier. 3 t This means for all members T sub Task t ; Configure the triggering mechanism for sub-real-time critical tasks to hardware interrupt mode and define the interrupt priority function. P 2( I n ),in I n For the first n There are several interrupt sources, and the interrupt priority corresponding to the real-time critical task is set to 1. P ( I real The interrupt set corresponding to the sub-real-time critical task is: I sub ; Configure sub-real-time critical task interruptsI sub priority P ( I sub () is the second highest level, satisfying the following inequality relationship: P ( I real )< P ( I sub )< P other ; in, P other This represents the priority set of all interrupts in the system, excluding real-time critical tasks.

[0018] This invention provides a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU. This method addresses hardware interrupt sources corresponding to sub-real-time critical tasks through system call interfaces. Request _ IRQ ( I sub_num , Handler sub , Flags sub ) Request a second interrupt handling interface for the sub-real-time critical task, where I sub_num This is the interruption number. Handler sub For the corresponding Interrupt Service Routine (ISR), the request process satisfies the following functional relationships: Status = Request _ IRQ ( I sub_num , Handler sub , Flags sub , DevName sub , DevID sub ); in, Flags sub Includes interrupt trigger type and shared interrupt flag; Status To return a status code, when Status =0 indicates that the application was successful. Handler sub Register as I sub_num The only processing entry point; Using interrupt affinity to set function Ψ( I sub_num ,C mask2 ),Will I sub_num Target processing core mask C mask2 Configured to include only the third core c 3. The formula is expressed as: Ψ( I sub_num , C mask2 → C mask2 ={ c 3}; That is, setting the interrupt descriptor irq desc The affinity mask in the code causes the interrupt controller to only send interrupts to the third core. c 3. Send an interrupt signal to physically block other cores from accessing the system. I sub_num The response; In the third core c 3. When a low-priority interrupt service routine... ISR low If during execution I sub_num Triggered, and the preemption enable condition is met. K preempt =1 and priority conditions P ( I sub )< P ( ISR low If this occurs, then a forced preemption will occur in the kernel execution flow: Execute ( I sub ) Execute ( ISR low) ; Meanwhile, if a real-time critical interruption occurs I real exist I sub Triggered during execution, due to P ( I real )< P ( I sub This creates a nested preemptive relationship: Execute ( I real ) Execute ( I sub ) Execute ( ISR low ); in, Execute ( I real This indicates that the execution of a real-time critical task was interrupted. I real , Execute ( I sub This indicates an interruption during the execution of a sub-real-time critical task. I sub , Execute ( ISR low This indicates that a low-priority interrupt service routine will be executed. ISR low ,symbol This refers to the logical relationship of preemption / priority execution.

[0019] This invention provides a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU, specifically for the third core of the CPU. c 3. Implement dedicated operating mechanisms and core synchronization strategies, including: Define the third core c The exclusive task set for 3 is Tc 3. Set Tc 3 is limited to the union of three subsets: frequency measurement interrupt handling task set. T freq Protection interrupt handling task set T prot and core data interaction threads T sync ; Through the CPU affinity mapping function Φ( T , C mask ), to set Tc 3. Bind to the third core c 3. Run the program, satisfying the following exclusive constraints: ; Wherein, Φ( Tc 3) Represents a set of tasks Tc 3. The set of CPUs allowed to run. t It is any task in the task set. It is a universal quantifier. t This means for all members Tc Task 3 t , C This refers to the set of all CPU cores in the system. Define the third core c 3 and the first core c The global shared data area between 1 is D global Data interaction thread T sync Responsible for the third core c 3 and the first core c Passing between 1 D global Status change; Introducing atomic operation locking mechanism A ( L ),set up V for D global The current value, V new For the new value to be written, V old For the original value, the atomic update operation satisfies the following logical formula: Success = CAS ( V old , V new ); in, CAS It is an atomic operation. Success for CAS The result of the operation process is marked when Success = True CAS operation successful; if Success = False ,but T sync Enter spin retry mode until the operation is successful; Define interrupt priority function P ( I ) and kernel preemption mode parameters K preempt ; Configure frequency measurement interrupt I freq and protection interruption I prot Its priority is the highest in the system. P max And satisfy: P ( I freq )= P ( I prot )= P min_val ; in,P min_val This represents the minimum value among the system priority values. P ( I freq )and P ( I prot These are frequency measurement interrupts. I freq and protection interruption I prot Prioritize; at the same time, configure the kernel preemption mode to be fully preemptible.

[0020] According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided, when the third core... c 3 is currently executing the data interaction thread. T sync Atomic operations in CAS If frequency measurement is interrupted I freq Or protection interruption I prot Triggered, the kernel scheduler immediately suspends based on the following preemption conditions. T sync : P ( I trigger )< P ( T sync )∧ K preempt =1 Context _ Switch ( ISR ); in, P ( I trigger To trigger an interrupt I freq / I prot Priority value; P ( T sync ) is the data interaction thread T sync Priority value; K preempt For kernel preemption mode parameters; Context_Switch(ISR) is the context switch operation; ISR is... I freq or I prot The processing procedure, after the ISR finishes execution, restores... Tsync The context and continue execution; Define inter-core communication bandwidth constraints B c1 c3 ,because T sync Only in the third core c Running on 3 cores, and using atomic locks to avoid bus locks or cache consistency storms, communication traffic is restricted to the first core. c 1 and the third core c Within the local cache synchronization range of 3.

[0021] According to the present invention, a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU is provided, which introduces a cache resource allocation mechanism, including: By utilizing the CPU's cache resource control register, the last-level cache LLC is divided into real-time partitions. W real Non-real-time partitioning W non ; Let the total number of cache paths be N The cache path mask allocated to the first core is M non It satisfies the following formula: ; in, k This is a parameter for the number of non-real-time cached paths. i For the summation index, the remaining path number N k Forced allocation to the second core c 2 and the third core c 3. Ensure that data from non-real-time tasks does not overwrite hot data from real-time tasks; Targeting the first core c Memory access of 1, configure memory bandwidth allocation threshold T bw ; Define the service life of the memory controller as Δ t Limitation within the cycle c The number of memory requests does not exceed 1. Ql imit : ; in, Ql imit As the first core c The maximum number of requests within a period of 1. For the first i One memory request, This represents the size of a single request.

[0022] Therefore, compared with the existing technology, the method for improving the real-time performance of Linux operating system applications based on multi-core CPU proposed in this invention has the following beneficial effects: 1. This invention, by employing a multi-core single-CPU architecture combined with a standard Linux system and real-time configuration, achieves a significant reduction in system cost while meeting high real-time performance requirements. Compared to traditional dual-CPU systems (one CPU running Linux and the other running a real-time application without an operating system), this invention offers a significantly lower cost, providing enterprises with a more economical and efficient solution for deployment in the field of industrial automation.

[0023] 2. This invention does not require any modification to the original Linux kernel code. Real-time performance can be improved simply by configuring startup parameters and adding necessary driver modules, which greatly simplifies the development process, reduces development difficulty and risk, and also facilitates subsequent system maintenance and upgrades.

[0024] 3. This invention improves system real-time performance while fully retaining all the original functions of the Linux system, including the file system, process management system, memory management system, network system, and other communication systems. This allows distribution network automation applications to fully utilize the powerful functions of the Linux system, reducing the development of corresponding functional modules and improving development efficiency. The use of a single-CPU architecture avoids complex communication processes between multiple CPUs, reducing system complexity and communication latency, further enhancing the system's real-time performance and stability.

[0025] 4. The technical solution proposed in this invention has good cross-platform compatibility. Previously, when porting the application code of the same solution to different platforms, very little code needed to be modified, which greatly saves the time and cost of code porting and improves development efficiency and market response speed.

[0026] 5. This invention achieves extremely low interrupt response latency by rationally allocating tasks across multiple CPU cores. Tasks with the highest real-time requirements (such as data sampling, frequency measurement, and protection) are assigned to independent cores and configured with the highest priority and interrupt preemptive mode. This meets the needs of application scenarios with extreme real-time requirements, such as distribution network automation. By employing a deterministic scheduling strategy, strict priority guarantees and predictable latency for critical tasks are ensured, improving system reliability and stability.

[0027] 6. The technical solution of this invention supports flexible configuration of CPU core task allocation and priority settings according to actual application needs, making it convenient for users to adjust and optimize according to specific scenarios. As business develops and demands increase, users can easily expand system performance by increasing the number of CPU cores or upgrading hardware configurations to meet future applications requiring higher real-time performance and larger scale.

[0028] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0029] Figure 1 This is a flowchart illustrating an embodiment of a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU, according to the present invention.

[0030] Figure 2 This is a flowchart of the system startup phase in an embodiment of a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU, according to the present invention.

[0031] Figure 3 This is a schematic diagram illustrating the modification of the bootargs parameter in an embodiment of a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU, according to the present invention.

[0032] Figure 4 This is a schematic diagram of the task allocation principle of the first core in an embodiment of a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU according to the present invention.

[0033] Figure 5 This is a schematic diagram of the task allocation principle of the second core in an embodiment of a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU according to the present invention.

[0034] Figure 6 This is a schematic diagram of the task allocation principle of the third core in an embodiment of a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU according to the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0036] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0037] See Figure 1 and Figure 2 This embodiment provides a method for improving the real-time performance of Linux operating system applications based on a multi-core CPU, including: During the system startup phase, by modifying the startup parameters of the Linux kernel, the core tasks of each core in the multi-core CPU are redistributed, and the basic running tasks of the Linux system are concentrated and distributed to run on the zeroth core. After the Linux kernel has finished booting and successfully loaded the root file system, the kernel driver module is loaded using a preset command to start the target application. When the target application creates a task, it sets the task affinity by calling system functions according to the task's real-time requirements. Assign non-real-time critical tasks to run on the first core; Real-time critical tasks are assigned to the second core for execution. By configuring the interrupt priority on the second core to the highest level and enabling the kernel's interrupt preemptive mode, high-priority interrupts can interrupt low-priority processing. At the same time, the corresponding system function is called through the interrupt number to request the first interrupt handling interface and set the first interrupt affinity. The secondary real-time critical task is assigned to run on the third core. The secondary real-time critical task is also configured to interrupt mode, and the interrupt priority on the third core is set to the second highest level, second only to the interrupt priority of the real-time critical task. The system function is called through the interrupt number to request the second interrupt handling interface, and the second interrupt affinity is set.

[0038] In this embodiment, since the CPU has more than four cores, the Linux boot parameters need to be modified when the BootLoader starts and loads the Linux kernel, and the tasks of the four cores need to be redistributed. All the original Linux system work is allocated to only one core, and after the entire Linux system starts normally on that core, the distribution automation application is started. The application is compiled into a kernel driver module and loaded into the kernel as the root user. All kernel threads started in the distribution automation application are restricted to one core by setting affinity. The data sampling task, which has the highest real-time requirements, is also allocated to a single core, as are the frequency measurement and protection-related tasks with the next highest real-time requirements. The tasks on each core are scheduled by the Linux kernel and do not interfere with each other. Data communication between cores is also handled by the Linux kernel, and access to global data between applications is controlled by a synchronization mechanism implemented in the application code for concurrency control.

[0039] During the bootloader's process of loading the Linux kernel, the boot parameters `bootargs` are modified to add configuration parameters that allow for the redistribution of core tasks, such as... Figure 3 As shown, the specific parameter configurations include: Use isolcpus=<cpu_list1> Parameter isolation is used to isolate other kernels besides the core that runs the basic tasks of the Linux system.<cpu_list1> This is a list of core numbers to be isolated, configured as isolcpus=1-3, to prevent basic Linux system tasks from being assigned to these cores; Use nohz_full=<cpu_list2> The parameter configuration specifies a completely clockless tick mode, where<cpu_list2> The core number list is configured to have no clock tick, i.e., nohz_full=1-3, to reduce clock interrupts on these cores, reduce task scheduling overhead, and improve real-time performance; Use rcu_nocbs=<cpu_list3> The parameter prevents the RCU (Read-Copy Update) mechanism from triggering callback functions on the specified core, where<cpu_list3> This is a list of core numbers where RCU callbacks are disabled, configured as rcu_nocbs=1-3, to prevent RCU callbacks from interfering with real-time tasks on these cores.

[0040] As can be seen, by configuring the above parameters, it is ensured that when the Linux system starts up, its basic running tasks only run on core 0, while other cores are isolated and optimized to be suitable for running real-time tasks, thereby realizing the redistribution of tasks among the cores in a multi-core CPU.

[0041] After the Linux kernel has finished booting and successfully loaded the root file system, the system enters the user-mode runtime environment; The kernel driver module loading operation is performed in user space using a preset command-line instruction. This command-line instruction is the insmod command or its equivalent, which is used to insert the compiled kernel driver module file into the Linux kernel, making it part of the kernel and starting its execution. After the kernel driver module is successfully loaded, it is used to initialize and start the target application for network distribution automation, including at least: allocating and initializing the system resources required for the application, registering interrupt handling functions, and creating the kernel threads required for the application; After the target application starts, it creates and initializes various task threads according to the task allocation strategy, including non-real-time critical tasks, real-time critical tasks, and sub-real-time critical tasks. In this process, when creating task threads, the target application sets the affinity of each task thread by calling the cpumask_set_cpu and set_cpus_allowed_ptr functions to ensure that non-real-time critical tasks, real-time critical tasks, and sub-real-time critical tasks are assigned to specific cores to run. Once the application starts, the system enters normal operation. Each task thread executes on its assigned core according to preset priorities and scheduling strategies, achieving the real-time requirements of the distribution network automation application.

[0042] After the target application is launched, the application enters the task creation and assignment phase; When creating a non-real-time critical task thread, the target application sets the affinity of the task thread by calling the `cpumask_set_cpu` and `set_cpus_allowed_ptr` functions. The specific setting process is as follows: Define a variable mask of type cpumask_t to represent the affinity setting of the CPU core; Use the cpumask_clear function to clear the mask variable, ensuring that no cores are selected in the initial state; The `cpumask_set_cpu` function sets the first core's ID to the `mask` variable, indicating that non-real-time critical task threads will be restricted to running on the first core. These tasks include network data transmission and reception, serial port data transmission and reception, 101 protocol tasks, 104 protocol tasks, temperature acquisition tasks, waveform recording tasks, and other tasks with low real-time requirements. The driver module restricts non-real-time tasks to run on the first core. Example code is as follows: const int cpu = 1; / / Specifies that the first core is numbered 1; cpumask_clear(&mask); cpumask_set_cpu(cpu,&mask); The `set_cpus_allowed_ptr` function is called, passing the pointer to the task thread whose affinity needs to be set and the configured mask variable as parameters, thereby restricting non-real-time critical task threads to run on the first core; example code is as follows: set_cpus_allowed_ptr(pointer to non-real-time critical task thread, &mask); Through the above steps, non-real-time critical tasks are successfully assigned to the first core to run, isolated from tasks on other cores and do not interfere with each other.

[0043] In this embodiment, as Figure 4 As shown, non-real-time critical tasks are assigned to run on the first core, including: Define the set of non-real-time critical tasks as T nonreal This includes all background tasks in the system that do not have strict limitations on response time, assuming the system's physical CPU core set is . C ={ c 0, c 1, c 2, c 3}, of which c 1 is the primary core; Set function Φ1 through CPU affinity. T , C This will aggregate non-real-time critical tasks. T nonreal Strictly bound to the first core c 1. Run the application and establish an exclusive or shared runtime environment that satisfies the following mapping relationship: 1 t ∈ T nonreal , Φ1( t )={ c1}; Wherein, Φ1( t ) indicates a task t The set of CPUs allowed to run, which is forcibly limited to containing only the first core. c 1. To achieve integration with the second core c 2 (Real-time critical tasks) and the third core c Physical isolation of 3 (sub-real-time critical tasks) t It is a set of non-real-time critical tasks T nonreal Any one of the tasks in, 1 is a universal quantifier. 1 t This means for all members T nonreal Task t .

[0044] For running on the first core c For non-real-time critical tasks on platform 1, configure the kernel scheduling policy to a normal time-sharing scheduling policy, such as... SCHED _ OTHER or SCHED _ NORMAL .

[0045] Define task priority function τ ( t The higher the value, the higher the priority (or according to the kernel implementation definition). Let the priority of a real-time critical task be... τ real The priority of the next real-time critical task is τ sub Non-real-time critical tasks have the following priority: τ non .

[0046] Configuration priority satisfies the following hierarchical inequality relationship: τ non < τ sub < τ real ; This means that non-real-time critical tasks have a lower priority than sub-real-time critical tasks and real-time critical tasks, ensuring that when there is competition for system resources, high real-time tasks can preempt CPU resources first, while non-real-time tasks can only get the opportunity to execute when the CPU is idle.

[0047] To prevent non-real-time critical tasks from interfering with the real-time core, a core load function is defined. L ( c i ) indicates the corec i The task load on the platform, through affinity binding, forces the following isolation constraints to be met: L ( c 1)∩ L ( c 2)= ∧ L ( c 1)∩ L ( c 3)= ; in, L ( c 1) L ( c 2) and L ( c 3) respectively in its core c 1. c 2 and c Task load on 3 As an empty set, the above constraints indicate the first core c Task load on 1 and second core c 2. The third core c The load on the 3 is physically decoupled, avoiding real-time jitter caused by cache coherency or bus contention.

[0048] During the system startup phase, kernel boot parameters or initialization scripts are used to migrate all basic Linux system daemons (such as non-critical processes like systemd and kthreadd) and user-space non-real-time applications to the first kernel. c 1. Run.

[0049] Using the CPU mask operation function Ψ cpu ( mask , c id Generate the first core c Mask of 1: mask 1=Ψ cpu (0,1); This mask is then applied to the creation interfaces of all non-real-time critical tasks (such as the cpumask parameter of the pthread_create or clone system calls) to ensure that tasks are constrained to the first core from the moment they are created. c In the scheduling queue of 1.

[0050] As can be seen, by using the core binding, priority hierarchy configuration and load isolation mechanism described above, non-real-time critical tasks are concentrated and restricted to running on the first core, while reserving clean computing resources for high real-time tasks on the second and third cores, thereby maximizing the overall real-time performance of the system under the multi-core architecture.

[0051] When creating real-time critical task threads, the application first sets the affinity of these task threads by calling the cpumask_set_cpu and set_cpus_allowed_ptr functions, restricting the real-time critical task threads to run on the second core. The specific setting process is similar to the method of setting affinity for non-real-time critical tasks mentioned above, except that the core number is specified as 2. For real-time critical tasks, further interrupt configuration is required: Configure interrupt priorities: During kernel configuration, ensure the kernel supports interrupt priority settings and enable real-time scheduling via kernel configuration options (such as CONFIG_PREEMPT_RT). In the application, set the priority of interrupts related to real-time critical tasks to the highest level by calling system-provided APIs (such as the interrupt handler specified when requesting an interrupt using the request_irq function, combined with setting the register values ​​of the interrupt controller; the specific implementation depends on the hardware platform). For example, in the ARM architecture, the priority of the corresponding interrupt can be set to the highest level by setting the priority register of the interrupt controller (such as GIC). Enable kernel interrupt preemptive mode: During the kernel configuration phase, enable kernel interrupt preemptive mode by setting kernel configuration options (such as relevant sub-options in CONFIG_PREEMPT_RT); this mode allows high-priority interrupts to be triggered and processed immediately during the handling of low-priority interrupts, thereby ensuring that interrupts of real-time critical tasks can be responded to in a timely manner. In the application, for interrupt handling of real-time critical tasks, the interrupt handling interface is requested by calling the corresponding system function (such as `request_irq`) using the interrupt number. During the request, interrupt affinity is set so that interrupt handling executes only on the secondary core. Specifically, when calling the `request_irq` function, a custom interrupt handling function is passed in, and the interrupt affinity is set within this function or through other related functions (such as `irq_set_affinity`), binding the interrupt to the secondary core. Example code is as follows: const unsigned int cpu_id = 2; / / Specifies the second core's ID as 2; cpumask_t mask; cpumask_clear(&mask); cpumask_set_cpu(cpu_id,&mask); irq_set_affinity(real-time critical task interrupt number, &mask); / / Binds the interrupt to the second core; Through the above steps, the real-time critical task was successfully assigned to run on the second core, and its interrupt priority was set to the highest level. At the same time, the kernel's interrupt preemptive mode was enabled to ensure that high-priority interrupts can interrupt low-priority processing, thereby meeting the extremely high response time requirements of the real-time critical task.

[0052] Because the data acquisition interrupt has the highest priority and the kernel is configured with interrupt preemption, the data acquisition interrupt can still be handled even when other lower-priority interrupts are running on the CPU's second core, or when a thread calls the `local_irq_disable` function to disable interrupts. This ensures a fast response, and the core runs the fewest tasks, significantly reducing task switching time. Besides running the data acquisition interrupt, this core only runs one data interaction thread between the second and first cores. When the two cores interact with global data, atomic locks are used for synchronization, resulting in minimal concurrent control operations and time on the nanosecond scale, which does not affect the fast response of the data acquisition interrupt.

[0053] Specifically, such as Figure 5 As shown, the set of real-time critical tasks is defined as follows: T real Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, through CPU affinity setting function Φ2( T , C mask Set up real-time critical tasks T real Strictly bound to the second core c 2. Establish a dedicated runtime environment that satisfies the following mapping relationships: 2 t ∈ T real ,Φ2( t )={ c 2}; Wherein, Φ2( t ) indicates a task t The set of CPUs allowed to run, and this set contains only the second core. c 2,t It is a set of real-time critical tasks. T real Any one of the tasks in, 2 is a universal quantifier. 2 t This means for all members T real Task t ; Define interrupt priority function P 1( I n ),in I n For the first n One interrupt source, for allocation to the second core c 2 Real-time critical task interruption I real Configure its priority to the highest level in the system. P max ,Right now: P ( I real )= P min_val ; in, P min_val This represents the minimum value among the system priority values ​​(the smaller the priority value, the higher the priority), ensuring... I real It wins over all other interrupt sources in the arbitration logic within the interrupt controller.

[0054] Configure kernel preemption mode parameters K preempt It is a preemptible state (i.e.) K preempt =1). In this mode, when the second core c 2. A low-priority interrupt service routine is being executed. ISR low If a real-time critical task is interrupted I real Triggered when the following preemption conditions are met: P ( I real )< P ( ISR low )∧ K preempt =1 Execute ( I real ) Execute (ISR low ); in, Execute ( I real This indicates that the execution of a real-time critical task was interrupted. I real , Execute ( ISR low This indicates that a low-priority interrupt service routine will be executed. ISR low ,symbol This refers to the preemptive / priority execution logic, specifically the interruption of high-priority real-time critical tasks. I real The execution immediately preempts the current low-priority interrupt service routine. ISR low The execution context does not need to wait for low-priority interrupts to complete.

[0055] Through system call interface Request _ IRQ ( I num , Handler , Flags ) Request real-time critical mission interruption I real The first interrupt handling interface, in which I num This is the interruption number. Handler This is a pointer to an interrupt service routine.

[0056] At the same time, the interrupt affinity setting function Ψ( I num , C mask1 ),Will I real Target processing core mask C mask1 Configured to include only the second core c 2. The formula is expressed as: Ψ( I num , C mask1 → C mask1 ={ c 2}; This ensures that interrupt signals are only received by the second core at the physical layer. c 2. Receiving and processing data to avoid cache invalidation and bus latency caused by cross-core scheduling.

[0057] Through the above-described formulaic configuration and mapping, physical isolation of real-time critical tasks on the second core, highest priority arbitration of interrupts, and strong preemption capability at the kernel level are achieved, thereby ensuring microsecond-level or even nanosecond-level real-time response.

[0058] In this embodiment, frequency measurement and protection-related tasks with the second highest real-time requirements are also assigned to a separate core, such as the third core of the CPU. These tasks are also configured in interrupt mode with the highest priority, strictly controlling the interrupt response latency within a specified time. This core does not run any other unrelated tasks besides inter-core data communication tasks. For example, the interrupt protection code is configured as follows: using the interrupt number of the protection interrupt handler, the `request_irq` function is called to request the protection interrupt handling interface; using the interrupt number `protect_irq_num`, the following code is called to set the interrupt affinity, restricting interrupt execution to run on the third core of the CPU: const unsigned int cpu_id = 3; cpumask_t mask; cpumask_clear(&mask); cpumask_set_cpu(cpu_id,&mask); irq_set_affinity(protect_irq_num,&mask); In addition to running frequency measurement and protection interrupts, the third core of the CPU only runs a data interaction thread between the third core and the first core. When the two cores interact with global data, atomic locks are used for synchronization, and the concurrent control operation does not affect the fast response to interrupts.

[0059] Specifically, such as Figure 6 As shown, the set of sub-real-time critical tasks is defined as follows: T sub Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, through the CPU affinity mapping function Φ3( T , c This will create a set of sub-real-time critical tasks. T sub Strictly bound to the third core c 3. Establish a dedicated runtime environment that satisfies the following mapping relationships: 3 t ∈ Tsub ,Φ3( t )={ c 3}; Among them, Φ3( t ) indicates a task t The set of CPUs allowed to run, and that set contains only the third core. c 3, t This is a set of real-time critical tasks. T sub Any one of the tasks in, 3 is a universal quantifier. 3 t This means for all members T sub Task t Ensure that subreal-time tasks and real-time critical tasks (running on) c 2) and non-real-time tasks (running in...) c 0 / c 1) Complete isolation at the physical core.

[0060] Configure the triggering mechanism for sub-real-time critical tasks to hardware interrupt mode and define the interrupt priority function. P 2( I n ),in I n For the first n There are several interrupt sources, with smaller values ​​indicating higher priority. Let the interrupt priority for a real-time critical task be... P ( I real (Highest level), the interrupt set corresponding to the sub-real-time critical task is I sub .

[0061] Configure sub-real-time critical task interrupts I sub priority P ( I sub () is the second highest level, satisfying the following inequality relationship: P ( I real )< P ( I sub )< P other ; in, P other This represents the priority set of all interrupts in the system except for real-time critical tasks (including non-real-time task interrupts, clock interrupts, etc.). This configuration ensures... Isub Only can be P ( I real It can preempt interrupts and simultaneously preempt all low-priority interrupts.

[0062] For hardware interrupt sources corresponding to sub-real-time critical tasks, i.e., the second interrupt I sub Unlike the first interrupt of a real-time critical task, this is achieved through a system call interface. Request _ IRQ ( I sub_num , Handler sub , Flags sub ) Request a second interrupt handling interface for the sub-real-time critical task, where I sub_num This is the interruption number. Handler sub For the corresponding Interrupt Service Routine (ISR), the request process satisfies the following functional relationships: Status = Request _ IRQ ( I sub_num , Handler sub , Flags sub , DevName sub , DevID sub ); in, Flags sub Includes interrupt trigger types (such as rising edge trigger) IRQF _ TRIGGER _ RISING ) and shared interrupt flag; Status To return a status code, when Status A value of 0 indicates a successful request, and the kernel will... Handler sub Register as I sub_num The only processing entry point.

[0063] To avoid the context switching overhead and cache consistency traffic caused by cross-core interrupt processing, interrupt affinity is used to set the function Ψ( I sub_num , C mask2 ),Will I sub_num Target processing core mask C mask2 Configured to include only the third corec 3. The formula is expressed as: Ψ( I sub_num , C mask2 → C mask2 ={ c 3}; That is, setting the interrupt descriptor irq desc The affinity mask in the code ensures that the interrupt controller (such as GIC or APIC) only sends interrupts to the third core. c 3. Send an interrupt signal (IPI / IRQ) to physically block other cores from accessing the system. I sub_num The response.

[0064] In the third core c 3. When a low-priority interrupt service routine... ISR low If during execution I sub_num Triggered, and the preemption enable condition is met. K preempt =1 and priority conditions P ( I sub )< P ( ISR low If this occurs, then a forced preemption will occur in the kernel execution flow: Execute ( I sub ) Execute ( ISR low) ; Meanwhile, if a real-time critical interruption occurs I real exist I sub Triggered during execution, due to P ( I real )< P ( I sub This creates a nested preemptive relationship: Execute ( I real ) Execute ( I sub ) Execute ( ISR low ); in,Execute ( I real This indicates that the execution of a real-time critical task was interrupted. I real , Execute ( I sub This indicates an interruption during the execution of a sub-real-time critical task. I sub , Execute ( ISR low This indicates that a low-priority interrupt service routine will be executed. ISR low ,symbol To establish a preemptive / priority execution logic, the hierarchical priority configuration described above is bound to the core, enabling efficient and low-jitter operation of sub-real-time critical tasks on independent cores.

[0065] For the third core of the CPU c 3. Implement dedicated operating mechanisms and core synchronization strategies, including: Define the third core c The exclusive task set for 3 is Tc 3. This set is strictly limited to the union of three subsets: the frequency measurement interrupt handling task set. T freq Protection interrupt handling task set T prot and core data interaction threads T sync .

[0066] Through the CPU affinity mapping function Φ( T , C mask ), to set Tc 3. Forced binding to a third core c 3. Run the program, satisfying the following exclusive constraints: ; Wherein, Φ( Tc 3) Represents a set of tasks Tc 3. The set of CPUs allowed to run. t It is any task in the task set. It is a universal quantifier. t This means for all members Tc Task 3 t , C This binding ensures that all CPU cores in the system are bound together. c 3. Do not process any unspecified tasks to avoid context switching overhead.

[0067] Define the third core c 3 and the first core c The global shared data area between 1 is D global Data interaction thread T sync Responsible for the third core c 3 and the first core c Passing between 1 D global Status change; To ensure data consistency during concurrent access, an atomic operation locking mechanism is introduced. A ( L ),when T sync Needs modification D global Instead of using traditional mutexes or semaphores, lock-free synchronization is achieved using hardware atomic instructions (such as Compare-And-Swap, CAS).

[0068] set up V for D global The current value, V new For the new value to be written, V old For the original value, the atomic update operation satisfies the following logical formula: Success = CAS ( V old , V new ); in, CAS It is an atomic operation. Success for CAS The result indicator of the operation process CAS The operation completes the read-compare-write process within a single instruction cycle, ensuring atomicity in a multi-core concurrent environment. Success = True CAS operation successful; if Success = False ,but T sync Enter spin retry mode until the operation is successful.

[0069] To ensure frequency measurement interruption I freq and protection interruption I prot Fast response is not blocked by atomic lock operations; define interrupt priority function. P( I ) and kernel preemption mode parameters K preempt .

[0070] Configure frequency measurement interrupt I freq and protection interruption I prot Its priority is the highest in the system. P max (Minimum value), and satisfies: P ( I freq )= P ( I prot )= P min_val ; in, P min_val This represents the minimum value among the system priority values ​​(the smaller the priority value, the higher the priority). P ( I freq )and P ( I prot These are frequency measurement interrupts. I freq and protection interruption I prot Priority; at the same time, configure the kernel preemption mode to be fully preemptible ( K preempt =1).

[0071] When the third core c 3 is currently executing the data interaction thread. T sync Atomic operations in CAS If frequency measurement is interrupted I freq Or protection interruption I prot Triggered, the kernel scheduler immediately suspends based on the following preemption conditions. T sync : P ( I trigger )< P ( T sync )∧ K preempt =1 Context _ Switch ( ISR ); in,P ( This is a priority mapping function: the input is a task / thread / interrupt, and the output is its priority value. P ( I trigger To trigger an interrupt I freq / I prot Priority value; P ( T sync ) is the data interaction thread T sync Priority value; K preempt For kernel preemption mode parameters, K preempt =1: The system is in a preemptive state (allowing high-priority tasks / interrupts to preempt the currently executing low-priority task). K preempt =0: The system is in a non-preemptive state; Context_Switch(ISR) is the context switch operation: when the preemption condition is met, the kernel scheduler performs the following operation: save the current thread. T sync The context (registers, stack pointer, etc.); switch to the interrupt service routine (ISR) for execution. The ISR is I freq or I prot The processing procedure, after the ISR finishes execution, restores... T sync The context is then used to continue execution.

[0072] Due to atomic operations CAS It requires very few CPU cycles (usually a single cycle or dozens of cycles) and does not involve process sleep or scheduling, so even if it is interrupted and preempted, the delay in resuming execution is extremely short (Jitter≈0).

[0073] Define inter-core communication bandwidth constraints B c1 c3 ,because T sync Only in the third core c Running on core 3, and using atomic locks to avoid bus locks or cache consistency storms, communication traffic is limited to the first core. c 1 and the third core c Within the synchronization range of the local cache (L1 / L2 Cache) of 3.

[0074] By setting interrupt affinity, ensure I freq and I prot Only c 3. Triggering and processing, its ISR (Interrupt Service Routine) has complete exclusive access during execution. c 3 computing resources, not with T sync Resource contention occurs, and it may only be possible to be [rejected] upon ISR return. T sync Seize, but because T sync Its priority is lower than that of interrupts, so it does not affect the real-time response to interrupts.

[0075] Through the above mechanism, the third core can interact with the first core only through lightweight atomic operations while handling high-frequency measurement and protection interrupts. This ensures the consistency of global data and, by utilizing the non-blocking nature of atomic operations and the highest priority preemption mechanism of interrupts, completely avoids the delay jitter caused by traditional locking mechanisms in interrupt response.

[0076] To further isolate the interference of non-real-time critical tasks on the real-time core, this embodiment introduces a Cache Allocation Technology (CAT) mechanism, specifically including... Cache partitioning configuration: Utilizing the CPU's cache resource control register, the last-level cache (LLC) is divided into real-time partitions. W real Non-real-time partitioning W non .

[0077] Let the total number of cache paths be N The cache path mask allocated to the first core is M non It satisfies the following formula: ; in, k This is a parameter for the number of non-real-time cached paths. i For the summation index, the remaining path number N k Forced allocation to the second core c 2 and the third core c 3. Ensure that data from non-real-time tasks does not overwrite hot data from real-time tasks.

[0078] Targeting the first core c Memory access of 1, configure memory bandwidth allocation (MBA) threshold.T bw .

[0079] Define the service life of the memory controller as Δ t Limitation within the cycle c The number of memory requests does not exceed 1. Ql imit : ; in, Ql imit As the first core c The maximum number of requests within a period of 1. For the first i One memory request, The size of a single request, when the first core c When the bandwidth usage of core 1 reaches a threshold, the memory controller forcibly inserts a wait state, thereby ensuring the second core's performance at the physical layer. c 2 and the third core c 3. It has a dedicated memory access channel.

[0080] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0081] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A method for improving the real-time performance of Linux operating system applications based on a multi-core CPU, characterized in that, include: During the system startup phase, by modifying the startup parameters of the Linux kernel, the core tasks of each core in the multi-core CPU are redistributed, and the basic running tasks of the Linux system are concentrated and distributed to run on the zeroth core. After the Linux kernel has finished booting and successfully loaded the root file system, the kernel driver module is loaded using a preset command to start the target application. When creating a task, the target application sets the task affinity by calling system functions based on the task's real-time requirements. Assign non-real-time critical tasks to run on the first core; Real-time critical tasks are assigned to run on the second core. By configuring the interrupt priority on the second core to the highest level and enabling the kernel's interrupt preemptive mode, high-priority interrupts interrupt low-priority processing. At the same time, the system function is called through the interrupt number to request the first interrupt handling interface and the first interrupt affinity is set; The secondary real-time critical task is assigned to run on the third core. The secondary real-time critical task is also configured to interrupt mode, and the interrupt priority on the third core is set to the second highest level, second only to the interrupt priority of the real-time critical task. The system function is called through the interrupt number to request the second interrupt handling interface, and the second interrupt affinity is set.

2. The method according to claim 1, characterized in that, During the BootLoader's boot process of loading the Linux kernel, the boot parameters `bootargs` are modified to add configuration parameters for the reallocation of core tasks. Specific configuration parameters include: Use isolcpus=<cpu_list1> Parameter isolation is used to isolate other kernels besides the core that runs the basic tasks of the Linux system.<cpu_list1> This is a list of core IDs to be isolated, configured as isolcpus=1-3; Use nohz_full=<cpu_list2> The parameter configuration specifies a completely clockless tick mode, where<cpu_list2> The core number list that is configured to have no clock tick, i.e., configured as nohz_full=1-3; Use rcu_nocbs=<cpu_list3> The parameter prevents the RCU mechanism from triggering callback functions on the specified core, where<cpu_list3> This is a list of core numbers where RCU callbacks are disabled, configured as rcu_nocbs=1-3.

3. The method according to claim 1, characterized in that, Assigning non-real-time critical tasks to run on the first core, including: Define the set of non-real-time critical tasks as T nonreal Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, of which c 1 is the primary core; Set function Φ1 through CPU affinity. T , C This will aggregate non-real-time critical tasks. T nonreal Bind to the first core c 1. Run the application and establish an exclusive or shared runtime environment that satisfies the following mapping relationship: 1 t ∈ T nonreal , Φ1( t )={ c 1}; Wherein, Φ1( t ) indicates a task t The set of CPUs allowed to run. t It is a set of non-real-time critical tasks T nonreal Any one of the tasks, 1 is a universal quantifier. 1 t This means for all members T nonreal Task t ; Define the core load function L ( c i ) indicates the core c i The task load on the platform, through affinity binding, forces the following isolation constraints to be met: L ( c 1)∩ L ( c 2)= ∧ L ( c 1)∩ L ( c 3)= ； in, L ( c 1) L ( c 2) and L ( c 3) respectively in its core c 1. c 2 and c Task load on 3 It is an empty set; During the system startup phase, the basic daemons and user-space non-real-time applications of the Linux system are migrated to the first kernel via kernel boot parameters or initialization scripts. c 1. Run; Using the CPU mask operation function Ψ cpu ( mask1 , c id Generate the first core c Mask of 1: mask 1=W cpu (0.1); and the first core c A mask of 1 is applied to the creation interface for all non-real-time critical tasks.

4. The method according to claim 1, characterized in that, Distribute real-time critical tasks to run on the second core, including: Define the set of real-time critical tasks as T real Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, the set of real-time critical tasks is configured through the CPU affinity setting function Φ2. T real Bind to the second core c 2. Establish a dedicated runtime environment that satisfies the following mapping relationships: 2 t ∈ T real ,Φ2( t )={ c 2}; Wherein, Φ2( t ) indicates a task t The set of CPUs allowed to run, and this set contains only the second core. c 2, t It is a set of real-time critical tasks. T real Any one of the tasks, 2 is a universal quantifier. 2 t This means for all members T real Task t .

5. The method according to claim 4, characterized in that: Define interrupt priority function P 1( I n ),in I n For the first n One interrupt source, for allocation to the second core c 2 Real-time critical task interruption I real Configure its priority to the highest level in the system. P max ,Right now: P ( I real )= P min_val ； in, P min_val This represents the minimum value among the system priority values; Configure kernel preemption mode parameters K preempt In a preemptible state, under kernel preemptive mode, when the second core... c 2. A low-priority interrupt service routine is being executed. ISR low If a real-time critical task is interrupted I real Triggered when the following preemption conditions are met: P ( I real )< P ( ISR low )∧ K preempt =1 Execute ( I real ) Execute ( ISR low )； in, Execute ( I real This indicates an interruption in the execution of a real-time critical task. I real , Execute ( ISR low This indicates that a low-priority interrupt service routine will be executed. ISR low ,symbol This refers to the preemptive / priority execution logic, specifically the interruption of high-priority real-time critical tasks. I real The execution immediately preempts the current low-priority interrupt service routine. ISR low The execution context; Through system call interface Request _ IRQ ( I num , Handler , Flags ) Request real-time critical mission interruption I real The first interrupt handling interface, in which I num This is the interruption number. Handler Pointer to an interrupt service routine; At the same time, the interrupt affinity setting function Ψ( I num , C mask1 ),Will I real Target processing core mask C mask1 Configured to include only the second core c 2. The formula is expressed as: Ψ( I num , C mask1 )→ C mask1 ={ c 2}。 6. The method according to claim 1, characterized in that, Distribute sub-real-time critical tasks to run on the third core, including: Define the set of sub-real-time critical tasks as T sub Let the system's physical CPU core set be... C ={ c 0, c 1, c 2, c 3}, through the CPU affinity mapping function Φ3( T , c This will create a set of sub-real-time critical tasks. T sub Binding to the third core c 3. Establish a dedicated runtime environment that satisfies the following mapping relationships: 3 t ∈ T sub ,Φ3( t )={ c 3}; Among them, Φ3( t ) indicates a task t The set of CPUs allowed to run. t This is a set of real-time critical tasks. T sub Any one of the tasks, 3 is a universal quantifier. 3 t This means for all members T sub Task t ; Configure the triggering mechanism for sub-real-time critical tasks to hardware interrupt mode and define the interrupt priority function. P 2( I n ),in I n For the first n There are several interrupt sources, and the interrupt priority corresponding to the real-time critical task is set to 1. P ( I real The interrupt set corresponding to the sub-real-time critical task is: I sub ; Configure sub-real-time critical task interrupts I sub priority P ( I sub () is the second highest level, satisfying the following inequality relationship: P ( I real )< P ( I sub )< P other ； in, P other This represents the priority set of all interrupts in the system, excluding real-time critical tasks.

7. The method according to claim 6, characterized in that: For hardware interrupt sources corresponding to sub-real-time critical tasks, the system call interface is used. Request _ IRQ ( I sub_num , Handler sub , Flags sub ) Request a second interrupt handling interface for the sub-real-time critical task, where I sub_num This is the interruption number. Handler sub For the corresponding Interrupt Service Routine (ISR), the request process satisfies the following functional relationships: Status = Request _ IRQ ( I sub_num , Handler sub , Flags sub , DevName sub , DevID sub )； in, Flags sub Includes interrupt trigger type and shared interrupt flag; Status To return a status code, when Status =0 indicates that the application was successful. Handler sub Register as I sub_num The only processing entry point; Using interrupt affinity to set function Ψ( I sub_num , C mask2 ),Will I sub_num Target processing core mask C mask2 Configured to include only the third core c 3. The formula is expressed as: Ψ( I sub_num , C mask2 )→ C mask2 ={ c 3}; That is, setting the interrupt descriptor irq desc The affinity mask in the code causes the interrupt controller to only send interrupts to the third core. c 3. Send an interrupt signal to physically block other cores from accessing the system. I sub_num The response; In the third core c 3. When a low-priority interrupt service routine... ISR low If during execution I sub_num Triggered, and the preemption enable condition is met. K preempt =1 and priority conditions P ( I sub )< P ( ISR low If this occurs, then a forced preemption will occur in the kernel execution flow: Execute ( I sub ) Execute ( ISR low) ； Meanwhile, if a real-time critical interruption occurs I real exist I sub Triggered during execution, due to P ( I real )< P ( I sub This creates a nested preemptive relationship: Execute ( I real ) Execute ( I sub ) Execute ( ISR low )； in, Execute ( I real This indicates an interruption in the execution of a real-time critical task. I real , Execute ( I sub This indicates an interruption during the execution of a sub-real-time critical task. I sub , Execute ( ISR low This indicates that a low-priority interrupt service routine will be executed. ISR low ,symbol This refers to the logical relationship of preemption / priority execution.

8. The method according to any one of claims 1 to 7, characterized in that, For the third core of the CPU c 3. Implement dedicated operating mechanisms and core synchronization strategies, including: Define the third core c The exclusive task set for 3 is Tc 3. Set Tc 3 is limited to the union of three subsets: frequency measurement interrupt handling task set. T freq Protection interrupt handling task set T prot and core data interaction threads T sync ; Through the CPU affinity mapping function Φ( T , C mask ), to set Tc 3. Bind to the third core c 3. Run the program, satisfying the following exclusive constraints: ； Wherein, Φ( Tc 3) Represents a set of tasks Tc 3. The set of CPUs allowed to run. t It is any task in the task set. It is a universal quantifier. t This means for all members Tc Task 3 t , C This refers to the set of all CPU cores in the system. Define the third core c 3 and the first core c The global shared data area between 1 is D global Data interaction thread T sync Responsible for the third core c 3 and the first core c Passing between 1 D global Status change; Introducing atomic operation locking mechanism A ( L ),set up V for D global The current value, V new For the new value to be written, V old For the original value, the atomic update operation satisfies the following logical formula: Success = CAS ( V old , V new )； in, CAS It is an atomic operation. Success for CAS The result of the operation process is marked when Success = True CAS operation successful; if Success = False ,but T sync Enter spin retry mode until the operation is successful; Define interrupt priority function P ( I ) and kernel preemption mode parameters K preempt ; Configure frequency measurement interrupt I freq and protection interruption I prot Its priority is the highest in the system. P max And satisfy: P ( I freq )= P ( I prot )= P min_val ； in, P min_val This represents the minimum value among the system priority values. P ( I freq )and P ( I prot These are frequency measurement interrupts. I freq and protection interruption I prot Prioritize; at the same time, configure the kernel preemption mode to be fully preemptible.

9. The method according to claim 8, characterized in that: When the third core c 3 is currently executing the data interaction thread. T sync Atomic operations in CAS If frequency measurement is interrupted I freq Or protection interruption I prot Triggered, the kernel scheduler immediately suspends based on the following preemption conditions. T sync : P ( I trigger )< P ( T sync )∧ K preempt =1 Context _ Switch ( ISR )； in, P ( I trigger To trigger an interrupt I freq / I prot Priority value; P ( T sync ) is the data interaction thread T sync Priority value; K preempt For kernel preemption mode parameters; Context_Switch(ISR) is the context switch operation; ISR is... I freq or I prot The processing procedure, after the ISR finishes execution, restores... T sync The context and continue execution; Define inter-core communication bandwidth constraints B c1 c3 ,because T sync Only in the third core c Running on 3 cores, and using atomic locks to avoid bus locks or cache consistency storms, communication traffic is restricted to the first core. c 1 and the third core c Within the local cache synchronization range of 3.

10. The method according to any one of claims 1 to 7, characterized in that, Introduce a cache resource allocation mechanism, including: By utilizing the CPU's cache resource control register, the last-level cache LLC is divided into real-time partitions. W real Non-real-time partitioning W non ; Let the total number of cache paths be N The cache path mask allocated to the first core is M non It satisfies the following formula: ； in, k This is a parameter for the number of non-real-time cached paths. i For the summation index, the remaining path number N k Forced allocation to the second core c 2 and the third core c 3. Ensure that data from non-real-time tasks does not overwrite hot data from real-time tasks; Targeting the first core c Memory access of 1, configure memory bandwidth allocation threshold T bw ; Define the service cycle of the memory controller as Δ t Limitation within the cycle c The number of memory requests does not exceed 1. Ql imit : ； in, Ql imit As the first core c The maximum number of requests within a period of 1. For the first i One memory request, This represents the size of a single request.

Images