In the previous article《The Fastest Real-Time Linux with Maximum Response Latency of 480 Nanoseconds Released by Guoke Huanyu》, we showcased the actual performance of the system achieving sub-microsecond end-to-end response, which garnered significant attention. This article provides key implementation paths and engineering points to facilitate users in quickly reproducing and further optimizing the results.
Linux is widely used in various scenarios due to its strong ecosystem, but it still faces skepticism in the real-time domain where deterministic requirements are extremely high, as the complexity of the monolithic kernel introduces more uncertainty. Essentially, the issues stem from two aspects: first, the uncertainty introduced by the coupling of kernel subsystems and multi-core scheduling; second, the competition conflicts caused by the deep hierarchy of modern CPUs/bus layers and the sharing of resources.
This article takes the ARMv8 architecture as an example and presents the method for achieving sub-microsecond IO response of WangHuo Real-Time Linux on the Phytium platform, starting from the CPU execution context.
Design Concept: Building a “No-Switch” Execution Environment on Isolated Cores
The core objective is to keep the designated CPU core always in a single process context, avoiding all context switches and interruptions, making its behavior approach that of a bare-metal environment. To achieve this, we implemented the Isolator technology, which maximally enhances determinism in the physical environment.
Implementation Approach: Isolator
-
CPU Isolation: By using the isolcpus parameter, the isolated core is removed from general scheduling and does not run ordinary user-space processes.
-
Highest Priority Binding: Set the target process to the highest priority of 99, with a FIFO scheduling policy, while allowing real-time tasks to monopolize the CPU without restrictions.
-
Interrupt Affinity Migration: Use the irqaffinity parameter to migrate peripheral interrupts to other cores, avoiding impact on the isolated core.
-
Freezing System Interrupts: Through kernel modifications, mask clock interrupts, inter-core interrupts, etc., to completely detach the isolated core from the existing mechanisms.
Hardware-Level Optimization: Further Enhancing Real-Time Performance
-
Avoiding Cache Misses: Implement critical code in assembly, using only general-purpose registers and minimizing memory access to avoid delays of hundreds of nanoseconds caused by DDR access.
-
Optimizing IO Address Mapping: Use ioremap_np to set the IO region as MT_DEVICE_nGnRnE, disabling caching, prefetching, and merging to enhance predictability.
-
Interrupt Polling: Enable peripheral interrupts, but mask CPU interrupt responses, actively polling the interrupt controller to obtain interrupt information, avoiding data read/write and processing delays introduced by interrupt context switching.
Testing API and Test Cases
-
API Description
int isolator_start(unsigned affinity_cpu); // Start the isolator
int isolator_rt_irq_pmd_run(unsigned irqnum, unsigned long flags, void (*func)(void)); // Blocking interrupt polling
-
Test Case gpio_test.ko Process
Step 1: Call isolator_start() on the designated core to enable the isolator function
Step 2: Implement GPIO multiplexing/direction/interrupt configuration
Step 3: Run the interrupt handler in polling mode (the code implementation should avoid memory access and complex logic as much as possible)
-
Key Implementation Details
GPIO Configuration
I/O mapping: Map GPIO0, GPIO1 to the kernel virtual space using ioremap_np.
Multiplexing: Switch GPIO0_0, GPIO1_12 to GPIO mode.
Direction: GPIO1_12 input, GPIO0_0 output.
Interrupt: Enable GPIO1_12, trigger on rising edge.
Return: Success 0; mapping failure -ENOMEM.GPIO Toggle
Mask GPIO1_12 interrupt.
Output pulse: Set GPIO0_0 high, insert about 1000 NOP cycles, then set low.
Restore GPIO1_12 interrupt and clear pending.Test Results and Notes
In continuous testing over 24 hours, the maximum delay was about 500ns, the minimum about 410ns, with a jitter of about 90ns. This is slightly lower than “Extreme Exploration I”, mainly because this implementation focuses more on usability and flexibility.
Users should avoid frequent I/O operations from other system processes during the testing code writing or testing process to prevent bus contention that affects real-time performance.
The real-time optimizations discussed in this article have been integrated into the WangHuo v2.4.0 Phytium beta version, and testing can begin by flashing the image.
For downloading the testing image and test code, please click“Read the Original” or
▼Open the link below▼
https://www.onewos.com/resource-center/iso
We will continue to release content on “Extreme Exploration of Linux”, so please stay tuned. More information can be searched under “WangHuo Real-Time Linux”
WangHuo Official Website
About WangHuo Real-Time Linux System
The WangHuo Real-Time Linux system is an embedded real-time operating system developed by Guoke Huanyu, featuring strong real-time capabilities, high reliability, functional safety, intelligence, strong compatibility, and a domestic ecosystem. Unlike traditional microkernel real-time operating systems, it fully supports the Linux ecosystem while providing robust industry middleware support, helping customers quickly build industry solutions. The WangHuo Real-Time Linux system is committed to building a domestic industrial chain for basic software and hardware, adapting to mainstream domestic chips and hardware platforms, providing complete domestic solutions, ensuring functionality and performance while avoiding bottleneck issues in critical areas.
Click the “Read the Original” below to download the testing image and test code