Performance optimization method and device of Linux system, electronic equipment and medium

Abstract

This application provides a method, apparatus, electronic device, and medium for optimizing the performance of a Linux system. The method includes: constructing a real-time kernel for the Linux system to be optimized, with task response determinism as the design goal; installing and starting the real-time kernel in the Linux system; setting the real-time kernel as the default boot option for the Linux system; and partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions to construct a three-level operating architecture consisting of a dedicated area for real-time tasks, an interrupt service area, and a general buffer area, thereby completing the real-time performance optimization configuration of the Linux system. Through hierarchical partitioning management of the CPU cores, real-time tasks, hardware interrupts, and kernel threads are strictly allocated to designated core areas for execution, achieving complete physical isolation between real-time tasks and system background tasks, and meeting the extreme requirement of deterministic response for real-time tasks.

Description

Technical Field

[0001] This invention relates to the field of operating system optimization, and more specifically, to methods, apparatus, electronic devices, and media for performance optimization of Linux systems. Background Technology

[0002] In applications with stringent requirements for task response latency, such as industrial control, real-time communication, and high-precision data acquisition, conventional Linux systems use a general scheduling mechanism by default, which is insufficient to meet the core requirements of task response determinism and low latency fluctuations.

[0003] In existing technologies, Linux systems are subject to multiple interference factors during runtime, including hardware interrupts, kernel threads, and direct memory access (DMA) latency. On the one hand, hardware interrupts and system kernel threads have no fixed core constraints, making them prone to preempting real-time task execution resources and causing real-time task execution to be interrupted. On the other hand, when the central processing unit enters a deep idle state, direct memory access operations are prone to generating additional latency, further exacerbating system jitter. At the same time, if high-frequency hardware interrupts are mixed with ordinary interrupts, interrupt handling efficiency will be greatly reduced, further affecting the stable operation of real-time tasks.

[0004] To address the aforementioned issues, most existing optimization solutions only adjust a single dimension, lacking systematic core resource partitioning management and fine-grained scheduling optimization. They cannot fundamentally isolate real-time tasks from system interference sources, making it difficult to achieve stable and controllable real-time optimization results. Therefore, there is an urgent need for a targeted Linux system performance optimization solution to address the technical shortcomings of existing technologies, such as poor real-time performance, large latency fluctuations, and unconstrained resource preemption. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a performance optimization method, device, electronic device and medium for Linux systems, which can strictly allocate real-time tasks, hardware interrupts and kernel threads to designated core areas for execution through hierarchical partitioning management of the central processing unit core, so as to achieve complete physical isolation between real-time tasks and system background tasks; and combined with DMA latency locking, CPU maximum performance frequency tuning and permanent kernel parameter optimization, etc., to eliminate random latency and fluctuations caused by system scheduling from the root, and meet the extreme requirements of real-time tasks for deterministic response.

[0006] In a first aspect, embodiments of this application provide a performance optimization method for a Linux system, the method comprising: In the real-time kernel configuration interface, build a real-time kernel for the Linux system to be optimized with the design goal of deterministic task response; The installation and startup of the real-time kernel are completed on the Linux system. Set the real-time kernel as the default boot option for the Linux system, and restart the Linux system after configuration; Based on multiple preset performance optimization dimensions, all central processing unit cores of the Linux system are partitioned to construct a three-level operating architecture consisting of a dedicated area for real-time tasks, an interrupt service area, and a general buffer area, thereby completing the real-time performance optimization configuration of the Linux system.

[0007] In one possible implementation, when the preset performance optimization dimension is CPU core isolation, all CPU cores of the Linux system are partitioned through the following steps: By using kernel boot parameters, multiple pre-defined first CPU cores in the Linux system are removed from the system's general scheduling pool to form a real-time task-specific region composed of all the first CPU cores, so that the first CPU cores in the real-time task-specific region are dedicated to executing real-time tasks.

[0008] In one possible implementation, when the preset performance optimization dimension is global interrupt migration optimization, all CPU cores of the Linux system are partitioned through the following steps: The processor affinity of all hardware interrupts in the Linux system is forcibly bound to multiple second CPU cores in the Linux system, excluding the first CPU core contained in the real-time task exclusive area, to form an interrupt service area composed of all second CPU cores, so that the second CPU cores in the interrupt service area are dedicated to executing hardware interrupt tasks.

[0009] In one possible implementation, when the preset performance optimization dimension is frequent interrupt fine-grained binding, all CPU cores of the Linux system are partitioned through the following steps: After the interrupt service region is formed, high-frequency hardware devices with interrupt frequencies greater than a preset frequency threshold are bound to at least one second central processing unit core within the interrupt service region, so that the interrupt tasks generated by the high-frequency hardware devices are executed by the bound second central processing unit core.

[0010] In one possible implementation, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: Configure the latency parameters for direct memory access to the CPU of the Linux system using kernel parameter configuration instructions to force the CPU to maintain a shallow idle state.

[0011] In one possible implementation, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: Set the frequency modulation strategy of all central processing unit cores in the Linux system to the highest frequency.

[0012] In one possible implementation, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: The kernel thread in the Linux system is bound to the second CPU core in the interrupt service region.

[0013] Secondly, embodiments of this application also provide a performance optimization device for a Linux system, the device comprising: Build modules are used to build a real-time kernel with task response determinism as the design goal for the Linux system to be optimized, through the real-time kernel configuration interface; The installation and startup module is used to complete the installation and startup of the real-time kernel in the Linux system; The configuration module is used to set the real-time kernel as the default boot option of the Linux system and restart the Linux system after configuration. The building module is also used to partition all the central processing unit cores of the Linux system based on multiple preset performance optimization dimensions to build a three-level operating architecture of real-time task dedicated area, interrupt service area and general buffer area, so as to complete the real-time performance optimization configuration of the Linux system.

[0014] In one possible implementation, when the preset performance optimization dimension is CPU core isolation, the building module is specifically used to partition all CPU cores of the Linux system through the following steps: By using kernel boot parameters, multiple pre-defined first CPU cores in the Linux system are removed from the system's general scheduling pool to form a real-time task-specific region composed of all the first CPU cores, so that the first CPU cores in the real-time task-specific region are dedicated to executing real-time tasks.

[0015] In one possible implementation, when the preset performance optimization dimension is global interrupt migration optimization, the building module is specifically used to partition all CPU cores of the Linux system through the following steps: The processor affinity of all hardware interrupts in the Linux system is forcibly bound to multiple second CPU cores in the Linux system, excluding the first CPU core contained in the real-time task exclusive area, to form an interrupt service area composed of all second CPU cores, so that the second CPU cores in the interrupt service area are dedicated to executing hardware interrupt tasks.

[0016] In one possible implementation, when the preset performance optimization dimension is frequent interruption fine-grained binding, the build module is specifically used to partition all CPU cores of the Linux system through the following steps: After the interrupt service region is formed, high-frequency hardware devices with interrupt frequencies greater than a preset frequency threshold are bound to at least one second central processing unit core within the interrupt service region, so that the interrupt tasks generated by the high-frequency hardware devices are executed by the bound second central processing unit core.

[0017] In one possible implementation, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the building module is further configured to configure the latency parameters of direct memory access of the CPU of the Linux system through kernel parameter configuration instructions to force the CPU to maintain a shallow idle state.

[0018] In one possible implementation, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the building module is further configured to set the frequency tuning strategy of all CPU cores in the Linux system to the highest frequency.

[0019] In one possible implementation, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the building module is further configured to bind kernel threads in the Linux system to a second CPU core in the interrupt service region.

[0020] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the performance optimization method for the Linux system as described in any of the first aspects.

[0021] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the performance optimization method for the Linux system as described in any of the first aspects.

[0022] This application provides a method, apparatus, electronic device, and medium for optimizing the performance of a Linux system. The method includes: constructing a real-time kernel with task response determinism as its design goal for the Linux system to be optimized in a real-time kernel configuration interface; installing and starting the real-time kernel in the Linux system; setting the real-time kernel as the default boot option for the Linux system; and restarting the Linux system after configuration. Based on multiple preset performance optimization dimensions, all CPU cores of the Linux system are partitioned to construct a three-level operating architecture consisting of a dedicated area for real-time tasks, an interrupt service area, and a general buffer area, thereby completing the real-time performance optimization configuration of the Linux system. This hierarchical partitioning management of the CPU cores allows for the strict allocation of real-time tasks, hardware interrupts, and kernel threads to designated core areas, achieving complete physical isolation between real-time tasks and system background tasks. Furthermore, combined with DMA latency locking, CPU maximum performance frequency tuning, and permanent kernel parameter optimization, it eliminates random latency and fluctuations caused by system scheduling at the source, meeting the extreme requirements of real-time tasks for response determinism. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a performance optimization method for a Linux system provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating the modification of real-time kernel configuration parameters provided in an embodiment of this application is shown; Figure 3 This illustration shows a schematic diagram of the structure of a performance optimization device for a Linux system provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0026] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0027] To enable those skilled in the art to utilize the content of this application, and in conjunction with the specific application scenario of "operating system optimization," the following implementation methods are provided. For those skilled in the art, the general principles defined herein can be applied to other embodiments and application scenarios without departing from the spirit and scope of this application. Although this application primarily describes the "operating system optimization field," it should be understood that this is merely an exemplary embodiment.

[0028] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0029] The following is a detailed description of a performance optimization method for a Linux system provided in the embodiments of this application.

[0030] Reference Figure 1 The diagram shown is a flowchart illustrating a performance optimization method for a Linux system provided in an embodiment of this application. The exemplary steps of this embodiment are described below: S101. In the real-time kernel configuration interface, build a real-time kernel for the Linux system to be optimized with the design goal of task response determinism.

[0031] In this application's implementation, the Linux system to be optimized refers to a task execution system that needs to meet task response latency requirements. The real-time kernel, designed with "task response determinism" as its design goal, does not prioritize overall Linux system speed, but rather ensures that once a real-time task is triggered, it must respond and complete within a deterministic, predictable, and stable timeframe, without allowing random delays, jitter, or sudden interruptions. The implementation process is as follows: First, the kernel in the Linux system is configured and initialized to reuse the kernel configuration currently in use by the Linux system, quickly generating a basic configuration file. Then, the relevant real-time kernel configuration parameters are modified in the real-time kernel configuration interface to build a real-time kernel for the Linux system to be optimized, with task response determinism as its design goal.

[0032] Specifically, to configure and initialize the kernel in a Linux system: Execute `yes''| make oldconfig` in the kernel source code directory of the Linux system: This will automatically confirm and load the original kernel configuration and generate the basic configuration file.

[0033] For a Linux kernel to compile and run, it must first have a configuration file named `.config`, which defines the kernel's supported features, drivers, and other functionalities. This command automatically reads existing kernel configuration files in the system directory (usually located in the ` / boot` directory, with filenames starting with `config-`). For configuration options added after kernel version updates, it automatically selects all default values, eliminating the need for manual confirmation and selection. This quickly generates a basic configuration file adapted to the current system, ensuring kernel configuration compatibility and avoiding errors from manual configuration.

[0034] Specifically, refer to Figure 2 The diagram shown is a flowchart illustrating the modification of real-time kernel configuration parameters according to an embodiment of this application. Specifically, the relevant real-time kernel configuration parameters are modified by accessing the real-time kernel configuration interface through the following steps: S201. In the Linux system's kernel source code directory, execute `make menuconfig`: This opens the real-time kernel configuration interface and enters the interactive configuration phase.

[0035] Executing this command will open a text-based graphical configuration window (ncurses-devel dependencies need to be installed beforehand for it to display correctly). In this interface, you can use the arrow keys and Enter key to interact and manually enable, disable, or modify various kernel features, such as enabling real-time kernel patches, adjusting scheduling policies, and configuring interrupt-related parameters. This is the most core and intuitive operation step for customizing a real-time kernel.

[0036] S202, the core configuration item for enabling the real-time kernel.

[0037] In this application's implementation, the core of the real-time kernel is low latency and high determinism, and these configuration items are all designed to achieve this goal: (1) Enable fully preemptible kernel (real-time): In the embodiments of this application, for the sake of performance, some core code segments of the ordinary kernel of the Linux system cannot be preempted, and real-time tasks may wait; after enabling the fully preemptible kernel, almost all kernel code can be preempted by high-priority real-time tasks, which completely reduces task response latency.

[0038] A. Configuration path: GeneralSetup→Preemption Model (Fully PreemptibleKernel (Real-Time)). B. Configuration operation: Select and enable the Fully Preemptible Kernel (Real-Time) option, and set the corresponding configuration item CONFIG_PREEMPT_RT to enabled (X) to enable the kernel's real-time preemption capability. CONFIG_PREEMPT_RT=X indicates that this feature is forcibly enabled during compilation.

[0039] (2) Enable high-resolution timer support: In the embodiments of this application, the precision of ordinary timers is usually 10ms / 1ms. After enabling high-resolution timer support CONFIG_HIGH_RES_TIMERS, the timer precision can reach the microsecond level, which meets the precise requirements of real-time tasks for time triggering (such as millisecond or even microsecond level task scheduling in industrial control).

[0040] A. Configuration path: General setup → Timers subsystem. B. Configuration operation: Check the HighResolution Timer Support option and set the corresponding configuration item CONFIG_HIGH_RES_TIMERS to enabled (*) to improve the time accuracy of the system timers and meet real-time requirements.

[0041] (3) Enable the full dynamic clock system (without ticking): In this embodiment, the ordinary kernel generates a "clock tick" at a fixed frequency (e.g., 100Hz) for task scheduling, time statistics, etc. It is triggered even when the system is idle, resulting in unnecessary kernel overhead. After enabling the full dynamic clock system CONFIG_NO_HZ_FULL, the clock tick on the isolated kernel will be completely turned off (tickless) and will only be triggered when there is a task that needs to be scheduled, which greatly reduces kernel scheduling overhead.

[0042] A. Configuration path: General setup → Timers subsystem → Timer tick handling (Full dynticks system (tickless)). B. Configuration operation: Select and enable the Full dynticks system (tickless) option, and set the corresponding configuration item CONFIG_NO_HZ_FULL to the enabled state (X) to disable the kernel periodic clock tick and reduce unnecessary kernel scheduling overhead.

[0043] (4) Set the timer frequency to 1000Hz: In this embodiment, the timer frequency determines the time slice granularity of kernel scheduling. 1000Hz means that 1000 clock interrupts are triggered per second, and the time slice granularity is 1ms (compared to 10ms for 100Hz). The scheduling granularity is finer, and the response latency of real-time tasks is smaller.

[0044] A. Configuration path: Processor type and features → Timer frequency. B. Configuration operation: Select the 1000HZ option, set the corresponding configuration item CONFIG_HZ_1000 to enabled (X), set the kernel timer frequency to 1000Hz, and improve the fineness of system time slice scheduling.

[0045] (5) Set the CPU frequency to performance mode: In the embodiments of this application, CPU dynamic frequency adjustment (such as powersave mode) will reduce the frequency according to the load, which may cause CPU performance fluctuations and increased latency when real-time tasks are running; after setting the default policy to performance, the CPU will always run at the highest frequency, eliminating the impact of frequency fluctuations on real-time performance.

[0046] A. Configuration path: Power management and ACPI options → CPU Frequencyscaling → CPU Frequencyscaling (CPU_FREQ [=y]) → Default CPUFreq governor. B. Configuration operation: Select the performance option, and set the corresponding configuration item CPU_FREQ_DEFAULT_GOV_PERFORMANCE to enabled (y). This sets the default CPU frequency scaling strategy to performance mode, ensuring the CPU runs at maximum performance and preventing frequency fluctuations from affecting real-time performance.

[0047] S203. Disable kernel signature-related configurations.

[0048] In this embodiment of the application, to avoid signature verification failure during kernel installation, a script is executed in the current kernel source code directory to disable signature-related configurations. Specific operations and instructions are as follows: a. Execute the following command to directly modify the kernel configuration file, disable signature verification-related configuration items, and clear the trusted key and revocation key configurations: Code block: 1. / scripts / config --disable SYSTEM_TRUSTED_KEYS \ 2.disable SYSTEM_REVOCATION_KEYS \ 3. Disable CONFIG_MODULE_SIG 4.disable CONFIG_MODULE_SIG_ALL \ 5.--set-str SYSTEM_TRUSTED_KEYS "" \ 6.--set-str SYSTEM_REVOCATION_KEYS "" Among them, SYSTEM_TRUSTED_KEYS: set to disabled state, clear configuration value; SYSTEM_REVOCATION_KEYS: set to disabled state, clear configuration value; CONFIG_MODULE_SIG: set to disabled state, turn off module signature verification; CONFIG_MODULE_SIG_ALL: set to disabled state, turn off signature requirements for all modules.

[0049] b. Execute `make olddefconfig`: This will apply the above signature-related configuration changes and update the kernel configuration file.

[0050] S204, Compile a real-time kernel.

[0051] In this embodiment, after completing all the above configurations, the compilation command is executed in the kernel source code directory to generate a kernel installation package in deb format. Specific operations and instructions are as follows: (1) Execute echo "-rt88-v1.0-$(date +%Y%m%d)">localversion-rt: Set the version suffix for the real-time kernel, including the RT version number (rt88-v1.0) and the compilation date (year, month, day format), and write it to the localversionrt file to distinguish between the custom real-time kernel and the system default kernel.

[0052] (2). Execute make -j nproc deb-pkg: compile the kernel in a multi-core parallel manner (nproc automatically obtains the number of CPU cores in the system to improve the compilation speed) and generate a deb format installation package. After compilation, the installation package will be generated in the parent directory of the source code directory.

[0053] S205. View the compiled files.

[0054] In this embodiment, the command `ls.. / *deb` is executed to view the real-time kernel deb installation packages generated in the parent directory. The installation packages generated in this compilation include the following four (based on version 5.15.191-rt88): (1).linux-headers-5.15.191-rt88-v1.0-20250922_5.15.191-rt88-v1.0-20250922-1_amd64.deb: Kernel header file installation package; (2) linux-image-5.15.191-rt88-v1.0-20250922-dbg_5.15.191-rt88-v1.0-20250922-1_amd64.deb: kernel debugging installation package; (3) .linux-image-5.15.191-rt88-v1.0-20250922_5.15.191-rt88-v1.0-20250922-1_amd64.deb: kernel image main installation package; (4).linux-libc-dev_5.15.191-rt88-v1.0-20250922-1_amd64.deb: Linux C library development file installation package.

[0055] S206. Generate the MD5SUM checksum of the installation package.

[0056] In this embodiment, to ensure the integrity of the installation package, the command `md5sum.. / *.deb` is executed in the kernel source code directory to calculate and generate the MD5SUM checksum for all deb installation packages. The checksums corresponding to the installation packages generated in this compilation are as follows: (1) Kernel header file package: 5a7389e47fcd72aaf046b43cd2f07409; (2) Kernel image main package: e8806c7247672f9e420be2fd5dc49058; (3) Kernel debugging package: 9a4f4802e622214c905ca5ecbbf04a18; (4) Linux C library development package: 21203a6b0076d1f8e43090564460c88a.

[0057] S102. Complete the installation and startup of the real-time kernel in the Linux system.

[0058] In the embodiments of this application, (1) among the four deb installation packages generated by the compilation of the installation packages to be installed, *-dbg* is the kernel debugging package, which does not need to be installed, and the installation packages to be kept are: a.linux-headers-5.15.191-rt88-v1.0-20250922_5.15.191-rt88-v1.0-20250922-1_amd64.deb; b.linux-image-5.15.191-rt88-v1.0-20250922_5.15.191-rt88-v1.0-20250922-1_amd64.deb; c.linux-libc-dev_5.15.191-rt88-v1.0-20250922-1_amd64.deb.

[0059] (2) Perform the installation operation. Enter the directory where the deb installation package is located, and execute the command sudo dpkg -i *.deb to install all the filtered real-time kernel installation packages through the dpkg package manager to complete the system deployment of the kernel.

[0060] S103. Set the real-time kernel as the default boot option for the Linux system, and restart the Linux system after configuration.

[0061] In the implementation of this application, (1) edit the GRUB boot configuration file: execute the command sudo nano / etc / default / grub to open the system GRUB boot configuration file, add the following configuration item at the end of the file to set the default boot kernel to the real-time kernel installed above: GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.15.191-rt88-v1.0-20250922".

[0062] Configuration instructions: Specify the GRUB default boot option as the 5.15.191-rt88 real-time kernel version under Ubuntu advanced options.

[0063] (2) Update GRUB configuration: Execute the command sudo update-grub to make the above GRUB boot configuration changes take effect. The system will regenerate the boot menu and set the real-time kernel as the default boot option.

[0064] (3) Reboot the system: Execute the sudo reboot command to reboot the system. The system will load and run the real-time kernel configured above to complete the kernel switch.

[0065] S104. Based on multiple preset performance optimization dimensions, all central processing unit cores of the Linux system are partitioned to construct a three-level operating architecture consisting of a dedicated area for real-time tasks, an interrupt service area, and a general buffer area, thereby completing the real-time performance optimization configuration of the Linux system.

[0066] In this embodiment, after the system starts the real-time kernel, the real-time performance of the kernel is further improved through multi-dimensional configurations such as CPU isolation, interrupt migration, DMA latency optimization, and CPU performance tuning, eliminating performance fluctuations during system operation. The optimized Linux system meets the task response latency requirements when executing tasks.

[0067] Specifically, when the preset performance optimization dimension is CPU core isolation, all CPU cores of the Linux system are partitioned through the following steps: using kernel boot parameters, multiple pre-defined first CPU cores in the Linux system are removed from the system's general scheduling pool to form a real-time task-specific region composed of all first CPU cores, so that the first CPU cores in the real-time task-specific region are dedicated to executing real-time tasks.

[0068] In this embodiment, the pre-defined number of first central processing unit (CPU) cores can be flexibly configured according to the actual real-time task load requirements and the total number of system cores. Core selection follows the principle of continuous core arrangement, further reducing the overhead of core scheduling. After the stripping and removal process is completed, the dedicated area for real-time tasks is completely removed from the system's regular task scheduling scope. The system's general scheduling process cannot allocate non-real-time tasks or ordinary processes to the cores in this area for execution, fundamentally preventing external tasks from preempting resources from real-time tasks and ensuring the independence and stability of the real-time task execution process. The real-time tasks to be processed by the first CPU core can be pre-bound by the user based on the actual application scenario.

[0069] Configuration example: Edit the ` / etc / default / grub` file and modify the `GRUB_CMDLINE_LINUX_DEFAULT` configuration item to the following: `GRUB_CMDLINE_LINUX_DEFAULT="quiet splash solcpus=0-3 nohz_full=` 0-3rcu_nocbs=0-3intel_pstate=disable Intel_idle.max_cstate=0processor.max_cs tate=1".

[0070] Configuration Description: • isocpus=0-3: Isolates CPU0 to CPU3 cores, using them only for real-time tasks to prevent ordinary tasks from consuming core resources; • nohz_full=0-3: Disables periodic clock ticks on isolated CPU0 to CPU3 cores, reducing kernel scheduling overhead; • rcu_nocbs=0-3: Removes RCU (Read-Copy Update) callback functions from CPU0 to CPU3 cores, preventing the RCU mechanism from affecting real-time tasks; • intel_pstate=disable: Disables Intel's built-in PSTATE frequency adjustment driver to prevent it from interfering with CPU performance configuration; • tel_idle.max_cstate=0: Limits the Intel CPU's idle state to C0, preventing the CPU from entering deep idle; • processor.max_cstate=1: Sets the maximum CPU idle state to C1, retaining only shallow idle, reducing CPU state switching latency. To apply the changes: Execute the command `sudo update-grub` to update the GRUB configuration. The configuration will take effect after restarting the system.

[0071] Specifically, when When the preset performance optimization dimension is global interrupt migration optimization, the following steps are used to partition all CPU cores of the Linux system: the processor affinity of all hardware interrupts in the Linux system is forcibly bound to multiple second CPU cores in the Linux system, excluding the first CPU core contained in the real-time task exclusive area, to form an interrupt service area composed of all second CPU cores, so that the second CPU cores in the interrupt service area are dedicated to executing hardware interrupt tasks.

[0072] In this embodiment, global interrupt migration is achieved through processor affinity binding, which can completely block the scheduling path of hardware interrupts to the dedicated area of ​​real-time tasks, avoid the hardware interrupts from preempting the running resources of the first CPU core when they are triggered, and thus prevent the real-time tasks from being interrupted due to interrupt response and the problem of excessive latency fluctuations. The second CPU core can also be reasonably divided into a number and range according to the number of system hardware interrupts and interrupt handling load. Moreover, the interrupt service area and the dedicated area of ​​real-time tasks are independent of each other and their resources do not overlap, further realizing the physical isolation between real-time tasks and system interrupt tasks and ensuring the determinism of real-time task response.

[0073] Example operation: Write a shell script named migrate_irq_to_12_15.sh with the following content. Execute the script to complete the global interrupt migration: Code block: 1.#! / bin / bash 2.# migrate_irq_to_12_15.sh 3. TARGET_MASK="F000" # Binary 1111 0000 0000 0000 CPU 12-15 4.for irq in $(awk -F: ' / ^[0-9]+ / {print $1}' / proc / interrupts); do 5.[[ -f / proc / irq / $irq / smp_affinity ]] || continue 6.echo $TARGET_MASK | sudo tee / proc / irq / $irq / smp_affinity> / dev / null 7. done Configuration instructions: TARGET_MASK="F000": Sets the interrupt affinity mask to F000, which corresponds to 1111 0000 0000 0000 in binary, binding all interrupts to CPU12 to CPU15 cores; iterates through all interrupt numbers in the / proc / interrupts file, and writes the mask value F000 to the / proc / irq / $irq / smp_affinity file for each interrupt, completing the interrupt migration.

[0074] Specifically, when the preset performance optimization dimension is fine-grained binding of frequent interrupts, the following steps are taken to partition all CPU cores of the Linux system: After forming the interrupt service region, high-frequency hardware devices with interrupt frequencies greater than the preset frequency threshold are bound to at least one second CPU core in the interrupt service region, so that the interrupt tasks generated by the high-frequency hardware devices are executed by the second CPU core bound to them.

[0075] In this embodiment, this step addresses the problem of high-frequency interrupts easily causing interrupt congestion and interfering with the processing of ordinary interrupts. It achieves high-frequency interrupt traffic control through dedicated binding, isolating high-load interrupt tasks from regular interrupt tasks and avoiding response delays caused by excessive single-core interrupt load. This optimization operation only schedules and allocates cores within the interrupt service region, without changing the original partitioning structure of the real-time task-specific region and the interrupt service region. This ensures efficient processing of high-frequency interrupts without interfering with the real-time task-specific cores, further improving the overall stability of system interrupt processing and continuously guaranteeing the deterministic operation and low latency characteristics of real-time tasks. Notably, the number of second CPUs bound to the high-frequency hardware devices is less than the number of second CPUs contained in the interrupt service region.

[0076] For devices that frequently experience interrupts, such as network interface cards (NICs), in addition to global interrupt migration, their interrupts are further bound to designated non-isolated cores to achieve fine-grained control over interrupt handling. Specific operations and instructions are as follows: 1. Execute the command `grep eno1 / proc / interrupts | awk -F: '{print $1}'` to query the interrupt number corresponding to the network card device eno1 (in this test, interrupt number 127 was returned). 2. Execute the command `echo 3000 |sudo tee / proc / irq / 127 / smp_affinity_list` to bind network card interrupt 127 to CPU12 to CPU13 cores; Additional notes: To bind to CPU14 to CPU15 cores, execute the command `echo c000 | sudotee / proc / irq / 127 / smp_affinity_list`.

[0077] In addition, all CPU cores in the Linux system, except those contained in the real-time task area and the interrupt service area, are allocated to the general buffer area.

[0078] Specifically, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: configuring the latency parameters of direct memory access of the Linux system's CPU through kernel parameter configuration instructions to force the CPU to maintain a shallow idle state.

[0079] In this embodiment, the Direct Memory Access (DMA) mechanism of the central processing unit can enable hardware to bypass the processor and directly access memory. However, when the processor enters a deep idle mode, DMA operation response latency and large fluctuations are prone to occur, which directly affects the stability of data interaction in real-time tasks. This step locks the direct memory access latency parameter to a fixed low value through kernel instructions, forces the processor to maintain a shallow idle mode of C1, and prevents the processor from entering a deep sleep power-saving state. This eliminates the additional latency and operation jitter caused by DMA operations from the root. Combined with the previous core partitioning and interrupt binding optimization, it comprehensively shields various system interference factors, further ensuring the deterministic response and low latency characteristics of real-time tasks, and adapting to the operational requirements of demanding real-time scenarios such as industrial control and high-precision acquisition.

[0080] Here, the configuration operation is as follows: Execute the command `sudo sh -c 'echo 0> / dev / cpu_dma_latency'` to write 0 to the ` / dev / cpu_dma_latency` file. Configuration explanation: This locks the CPU's DMA latency parameter to 0 microseconds and forces the CPU to remain in the C1 idle state, preventing delays caused by DMA operations and CPU state switching from affecting real-time tasks.

[0081] Specifically, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes setting the frequency adjustment strategy of all CPU cores in the Linux system to the highest frequency.

[0082] In this embodiment, conventional Linux systems typically employ a dynamic frequency and voltage adjustment strategy by default. The processor cores automatically adjust their operating frequency based on the load. This frequency fluctuation process generates scheduling latency and performance volatility, directly impacting the execution stability and response speed of real-time tasks. This step locks all CPU core frequency adjustment strategies to the highest performance mode, maintaining the rated maximum operating frequency, and eliminates dynamic frequency reduction and energy-saving frequency adjustment mechanisms. Combined with previous core partitioning, interrupt binding, and direct memory access latency optimization, this further eliminates the performance loss caused by frequency fluctuations, ensuring that the dedicated cores for real-time tasks and interrupt service cores maintain full-load stable operation throughout the process. This comprehensively reduces system response latency and thoroughly meets the stringent requirements for task response determinism and ultra-low latency in scenarios such as industrial control and high-precision data acquisition.

[0083] Configuration steps: Execute `echo performance | sudo tee / sys / devices / system / cpu / cpu*` / cpufreq / scaling_governor command.

[0084] Configuration instructions: Set the frequency adjustment strategy of all CPU cores in the system to performance mode to allow the CPU to run at the highest frequency continuously, avoiding performance fluctuations caused by dynamic frequency adjustment.

[0085] Optionally, after partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes binding kernel threads in the Linux system to a second CPU core in the interrupt service region.

[0086] In this embodiment, the Linux system kernel threads include various core operation and maintenance threads such as the soft interrupt handling thread ksoftirqd, kernel background service threads, kworker, and rcu. These threads can be randomly scheduled on all CPU cores of the system by default. If they run in the dedicated area of ​​real-time tasks, they are very likely to preempt the core resources and execution time slices of real-time tasks, resulting in real-time task response delays and execution interruptions. This step configures processor affinity parameters to bind all kernel threads to the second CPU core in the interrupt service area, achieving complete isolation between kernel threads and the core resources of real-time tasks. This ensures that kernel threads can only run in the interrupt service area and do not intrude on the dedicated core of real-time tasks. Combined with the previous interrupt migration and high-frequency interrupt optimization, this further blocks the interference of system background tasks on real-time performance and builds a disturbance-free running environment for real-time tasks.

[0087] Configuration Operation: Execute the following script to bind the relevant kernel threads to CPU12 through CPU15 cores. Code Block: for pid in $(ps -eo pid,comm | awk ' / kworker|ksoftirqd|rcu_sched|rcu_bh / {p rint$1}'); dosudo taskset -pc 12-15 $piddone.

[0088] Configuration instructions: Iterate through the process IDs of all kworker (kernel worker threads), ksoftirqd (soft interrupt handling threads), and rcu_sched / rcu_bh (RCU-related threads) in the system, and bind them to CPU12 to CPU15 cores using taskset-pc12-15.

[0089] Specifically, disable the hyper-threading (SMT) of the first CPU core in the real-time task-specific region.

[0090] In this embodiment, the synchronous multithreading (SMT) function of the central processing unit is disabled by executing the kernel parameter configuration command `echo off | sudo tee / sys / devices / system / cpu / smt / control`. The core function of this configuration is to eliminate the hardware resource contention problem of multiple logical cores within the same physical core under hyper-threading technology, avoid resource contention between logical cores causing fluctuations in the execution latency of real-time tasks, further improve the stability and deterministic response of real-time tasks running on isolated cores, and ensure that the execution timing of real-time tasks on isolated cores is predictable and undisturbed.

[0091] Specifically, disable the hyper-threading (SMT) of the first CPU core in the real-time task-specific region.

[0092] Specifically, a real-time thread is started and the real-time thread is restricted to run on the first central processing unit core in the dedicated area of ​​the real-time task, thereby testing the real-time response capability of the first central processing unit core.

[0093] In this embodiment, starting a real-time thread and limiting its execution to isolated cores is a verification operation of the real-time optimization effect of the Linux system. The specific command executed is `sudo taskset -c 0-3 chrt -f 99cyclictest -m -Sp95 -i2000 -d3m`. The core configuration logic of this command is as follows: `taskset-c0-3`: Through processor affinity constraints, the execution scope of subsequently started test processes is strictly limited to the pre-isolated CPU0 to CPU3 cores (i.e., the dedicated area for real-time tasks), ensuring that the test processes only occupy the dedicated core resources for real-time tasks and do not interfere with the normal operation of the interrupt service area cores; `chrt -f 99`: Configures the scheduling policy of the test processes to a FIFO (First-In-First-Out) real-time scheduling policy and sets its real-time priority to 99 (Linux). The system's highest real-time priority is set to ensure that the test process has the highest execution priority within the isolated core, simulating the scheduling characteristics of critical real-time tasks in industrial scenarios. `cyclictest-m-Sp95-i2000-d3m`: This starts the real-time testing tool `cyclictest`, locking the test process's memory space using the `-m` parameter to avoid unexpected delays caused by memory paging. `-Sp95` sets the sampling thread priority to 95, ensuring the accuracy of the sampled data. `-i2000` sets the test interrupt interval to 2000 microseconds, simulating the triggering scenario of high-frequency real-time tasks. `-d3m` sets the continuous test duration to 3 minutes to obtain statistically significant real-time response latency data, verifying the actual effect of core isolation, interrupt migration, and other optimization measures on improving task response determinism.

[0094] Optionally, permanent optimization of system kernel parameters can be performed. Permanent optimization of system kernel parameters is a low-level configuration fixation operation aimed at improving real-time performance. Its core purpose is to reduce random scheduling jitter during system operation and improve the stability and determinism of real-time task response by modifying kernel scheduling, memory management, and timer-related parameters. Specifically, this is achieved by creating the ` / etc / sysctl.d / 99-rt.conf` configuration file and writing the following kernel parameters to make them permanently effective: 1.kernel.sched_rt_runtime_us = -1; 2.kernel.sched_rt_period_us = 1000000; 3. vm.stat_interval = 120; 4. kernel.timer_migration = 0. The configuration logic and function of each parameter are as follows: `kernel.sched_rt_runtime_us = -1`: Removes the runtime quota limit for real-time tasks in the Linux system, allowing critical real-time tasks to continuously occupy core resources and avoid interruption by the scheduler due to runtime exhaustion, ensuring the continuity of real-time task execution. `kernel.sched_rt_period_us = 1000000`: Sets the scheduling period of real-time tasks to 1,000,000 microseconds (i.e., 1 second), consistent with the system's default scheduling period. While removing the runtime limit for real-time tasks, it maintains compatibility with the system's original scheduling framework, avoiding scheduling anomalies caused by parameter conflicts. `vm.stat_interval = 120`: Adjusts the time interval for virtual memory status statistics to 120 seconds, significantly reducing the system overhead caused by the kernel's periodic memory status statistics and minimizing interference from memory statistics operations on real-time tasks. `kernel.timer_migration = 0`: Disables the automatic migration function of the real-time kernel timer between different CPU cores, fixing the timer's running core and eliminating scheduling latency and response jitter caused during timer migration.

[0095] Here, the core effect of this optimization step is: it can reduce system random scheduling jitter by 5-20 microseconds. Although it does not significantly reduce the maximum response latency of real-time tasks, it can effectively reduce the frequency of unexpected latency "glitch" occurrences, further improve the predictability of real-time task response timing, and form a comprehensive real-time guarantee system in conjunction with optimization measures such as core isolation and interrupt binding.

[0096] In addition, to verify the optimization effect of the real-time kernel, real-time performance tests were conducted on the system's default ordinary kernel and the custom optimized real-time kernel under both stress and no-stress scenarios. The test results were compared to verify the performance improvement of the real-time kernel. The specific test steps and results are as follows: Step 1: Install testing tools. Execute the command `sudo apt install -y rt-tests stress-ng` to install the real-time testing toolset rttests (which includes the cyclictest core testing tool) and the system stress testing tool stress-ng.

[0097] Step 2: Standard Kernel Testing (System default 5.19.0-32-generic). First, check the version information of the system's default standard kernel to confirm the test environment, and then perform stress-free and stress-based tests: (1) Check the kernel version by executing the uname -v and uname -r commands to confirm that the kernel version is 5.19.0-32-generic, which is the default non-real-time kernel of the Ubuntu system.

[0098] (2) No-stress test. Operation: Execute the command `sudo cyclictest -l100000 -m -Sp90 -i200 -d60s` to start the cyclictest test: 100,000 test runs, memory locked, sampling priority 90, interrupt interval 200 microseconds, test duration 60 seconds. Test results: The minimum latency for real-time tasks on each CPU core was 1 microsecond, the average latency was 1 microsecond, and the maximum latency reached 30 microseconds. Some cores showed slight latency fluctuations.

[0099] (3) Stress test. Step i: Execute the command `stress-ng --cpu 4 --io 2 --vm 2 --vm-bytes80% -t 5m&` to apply stress to the system: 4 CPUs at full load, 2 IO stress processes, 2 memory stress processes (occupying 80% of memory), stress lasting for 5 minutes; Step ii: Execute the command `sudo cyclictest -m -Sp90 -i200-d3m` under stress scenario to perform a 3-minute real-time test. Test results: The minimum and average latency of each CPU core remained at 1 microsecond, but the maximum latency soared to 14000 microseconds, and multiple cores exhibited severe latency spikes, resulting in extremely poor real-time performance.

[0100] Step 3: Real-time kernel testing (custom 5.15.191-rt88). After switching to the optimized real-time kernel, first check the kernel version information, then perform stress-free and stress-bearing tests in the same scenario to ensure the comparability of the tests: (1) Check the real-time kernel version. Execute the uname -r command to confirm that the system has loaded the custom real-time kernel version 5.15.191-rt88.

[0101] (2) Stress-free test. Operation: Execute the same command as the normal kernel stress-free test: sudocyclictest -l100000 -m -Sp90-i200 -d60s. Test results: The minimum latency of each CPU core is 1 microsecond, the average latency is 1 microsecond, and the maximum latency is only 13 microseconds. Compared with the normal kernel stress-free scenario, the maximum latency is reduced by 56.7%, and there is no obvious latency fluctuation.

[0102] (3) Stress test. Step 1: Execute the same stress command as the normal kernel stress test: stress-ng --cpu 4 --io 2 --vm2 --vm-bytes 80% -t 5m&; Step 2: Execute the command sudo cyclictest -m -Sp90 -i200 -d3m under the same stress scenario to perform a 3-minute real-time test. Test results: The minimum latency of each CPU core is 1 microsecond, the average latency is 1-3 microseconds, and the maximum latency is only 35 microseconds. Compared with the normal kernel stress scenario, the maximum latency is reduced by 99.75%, the system has no obvious latency spikes, and the real-time performance and stability are significantly improved.

[0103] Step 4: Test Conclusions. Through comparative testing of the regular kernel and the optimized real-time kernel, the following conclusions can be drawn: 1. Under no-stress scenarios, the maximum latency of the real-time kernel is significantly reduced compared to the regular kernel, resulting in a significant improvement in system determinism; 2. Under stressful scenarios, the regular kernel experiences severe latency spikes, while the real-time kernel maintains extremely low maximum latency, demonstrating strong anti-interference capabilities; 3. This multi-dimensional real-time kernel optimization strategy (CPU isolation, interrupt migration, DMA latency optimization, etc.) effectively eliminates system performance fluctuations, achieving highly deterministic real-time performance and meeting the application requirements of real-time Linux systems.

[0104] Based on the same inventive concept, this application also provides a Linux system performance optimization device corresponding to the Linux system performance optimization method. Since the principle of the device in this application is similar to the Linux system performance optimization method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0105] Reference Figure 3 The diagram shown is a schematic of a performance optimization device for a Linux system provided in an embodiment of this application. The device includes: Module 301 is used to build a real-time kernel with task response determinism as the design goal for the Linux system to be optimized in the real-time kernel configuration interface. The installation and startup module 302 is used to complete the installation and startup of the real-time kernel in the Linux system; Configuration module 303 is used to set the real-time kernel as the default boot option of the Linux system, and restart the Linux system after configuration is completed; The construction module 301 is also used to partition all the central processing unit cores of the Linux system based on multiple preset performance optimization dimensions to build a three-level operating architecture of real-time task dedicated area, interrupt service area and general buffer area, so as to complete the real-time performance optimization configuration of the Linux system.

[0106] Here, this device can strictly allocate real-time tasks, hardware interrupts, and kernel threads to designated core areas for execution through hierarchical partitioning management of the central processing unit core, achieving complete physical isolation between real-time tasks and system background tasks; and combined with DMA latency locking, CPU maximum performance frequency tuning, and permanent kernel parameter optimization, it eliminates random delays and fluctuations caused by system scheduling at the source, meeting the ultimate requirement of real-time tasks for deterministic response.

[0107] like Figure 4 As shown in the figure, an electronic device 400 provided in this application embodiment includes: a processor 401, a memory 402 and a bus. The memory 402 stores machine-readable instructions that can be executed by the processor 401. When the electronic device is running, the processor 401 communicates with the memory 402 through the bus. The processor 401 executes the machine-readable instructions to perform the steps of the performance optimization method of the Linux system described above.

[0108] Specifically, the memory 402 and processor 401 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 401 runs the computer program stored in the memory 402, it can execute the performance optimization method of the Linux system mentioned above.

[0109] Corresponding to the above-described performance optimization method for Linux systems, this application embodiment also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the above-described performance optimization method for Linux systems.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0111] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0112] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0113] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0114] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A performance optimization method for a Linux system, characterized in that, The method includes: In the real-time kernel configuration interface, build a real-time kernel for the Linux system to be optimized with the design goal of deterministic task response; The installation and startup of the real-time kernel are completed on the Linux system. Set the real-time kernel as the default boot option for the Linux system, and restart the Linux system after configuration; Based on multiple preset performance optimization dimensions, all central processing unit cores of the Linux system are partitioned to construct a three-level operating architecture consisting of a dedicated area for real-time tasks, an interrupt service area, and a general buffer area, thereby completing the real-time performance optimization configuration of the Linux system.

2. The performance optimization method for a Linux system according to claim 1, characterized in that, When the preset performance optimization dimension is CPU core isolation, the following steps are used to partition all CPU cores of the Linux system: By using kernel boot parameters, multiple pre-defined first CPU cores in the Linux system are removed from the system's general scheduling pool to form a real-time task-specific region composed of all the first CPU cores, so that the first CPU cores in the real-time task-specific region are dedicated to executing real-time tasks.

3. The performance optimization method for a Linux system according to claim 1, characterized in that, When the preset performance optimization dimension is global interrupt migration optimization, the following steps are used to partition all CPU cores of the Linux system: The processor affinity of all hardware interrupts in the Linux system is forcibly bound to multiple second CPU cores in the Linux system, excluding the first CPU core contained in the real-time task exclusive area, to form an interrupt service area composed of all second CPU cores, so that the second CPU cores in the interrupt service area are dedicated to executing hardware interrupt tasks.

4. The performance optimization method for a Linux system according to claim 3, characterized in that, When the preset performance optimization dimension is frequent interrupt fine-grained binding, the following steps are used to partition all CPU cores of the Linux system: After the interrupt service region is formed, high-frequency hardware devices with interrupt frequencies greater than a preset frequency threshold are bound to at least one second central processing unit core within the interrupt service region, so that the interrupt tasks generated by the high-frequency hardware devices are executed by the bound second central processing unit core.

5. The performance optimization method for a Linux system according to claim 1, characterized in that, After partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: Configure the latency parameters for direct memory access to the CPU of the Linux system using kernel parameter configuration instructions to force the CPU to maintain a shallow idle state.

6. The performance optimization method for a Linux system according to claim 1, characterized in that, After partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: Set the frequency modulation strategy of all central processing unit cores in the Linux system to the highest frequency.

7. The performance optimization method for a Linux system according to claim 1, characterized in that, After partitioning all CPU cores of the Linux system based on multiple preset performance optimization dimensions, the method further includes: The kernel thread in the Linux system is bound to the second CPU core in the interrupt service region.

8. A performance optimization device for a Linux system, characterized in that, The device includes: Build modules are used to build a real-time kernel with task response determinism as the design goal for the Linux system to be optimized, through the real-time kernel configuration interface; The installation and startup module is used to complete the installation and startup of the real-time kernel in the Linux system. The configuration module is used to set the real-time kernel as the default boot option of the Linux system and restart the Linux system after configuration. The building module is also used to partition all the central processing unit cores of the Linux system based on multiple preset performance optimization dimensions to build a three-level operating architecture of real-time task dedicated area, interrupt service area and general buffer area, so as to complete the real-time performance optimization configuration of the Linux system.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the performance optimization method for a Linux system as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the performance optimization method for the Linux system as described in any one of claims 1 to 7.

Images