Real-time window switching method and device based on shared memory and hardware monitoring instruction

Abstract

The application provides a real-time window switching method and device based on shared memory and hardware monitoring instructions. The method comprises: configuring a local timer of a target processor into an end time trigger mode, and setting an entry of an interrupt vector as a bare interrupt processing entry bypassing a kernel standard interrupt entry and exit framework; during execution of the bare interrupt processing entry, independently maintaining per-processor dynamic tick accounting, and triggering an original timing interrupt path according to a preset interrupt period; a user state real-time thread sets hardware address monitoring on a cache line where a window state identifier is located, executes low-power consumption waiting with window end time constraints during a non-real-time window, after exiting the waiting due to shared memory page writing, confirms a window switching result in combination with a serial number and a window state identifier, and executes a corresponding real-time workload according to a real-time window start time stamp. The application can reduce window switching perception delay, improve real-time response certainty, and reduce system deployment and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a real-time window switching method and apparatus based on shared memory and hardware monitoring instructions. Background Technology

[0002] As the demands for deterministic task response in applications such as industrial control, robot control, and high-frequency trading continue to increase, achieving real-time window switching at the microsecond or even sub-microsecond level on a general-purpose Linux operating system has become a significant technical challenge in the field of real-time computing. Existing solutions employ various methods. One approach involves the kernel sending real-time notifications to user-space threads via signals or completion parameters. However, this approach requires a complete path including hardware interrupt handling, software interrupt handling, scheduler checks, and user-space wake-up, resulting in significant notification latency and jitter. Another approach reduces scheduling latency through the PREEMPT_RT patch, but still relies on the Linux scheduler for task switching, making it difficult to overcome scheduler overhead limitations.

[0003] Other solutions employ dual-kernel architectures such as Xenomai and RTAI, or hardware isolation methods like Jailhouse. While these can reduce latency, they suffer from drawbacks such as requiring kernel source code modifications, complex deployment and maintenance, or the inability to utilize file systems and network protocol stacks outside the Linux environment for real-time tasks. Therefore, existing technologies generally suffer from the following shortcomings: either they notify path-dependent Linux interrupt frameworks and schedulers, resulting in high perceived latency during window switching; or they require kernel modifications or the introduction of dedicated runtime environments, leading to poor versatility and maintainability, making it difficult to achieve sub-microsecond real-time window switching without modifying the Linux kernel source code or leaving the Linux user-space environment. Summary of the Invention

[0004] In view of this, embodiments of this application provide a real-time window switching method and apparatus based on shared memory and hardware monitoring instructions to solve the problems of high interrupt framework overhead, large scheduling wake-up delay, and uncertain real-time window switching perception in the prior art.

[0005] A first aspect of this application provides a real-time window switching method based on shared memory and hardware monitoring instructions, comprising: allocating shared memory pages for a target processor in a general-purpose operating system kernel through a loadable kernel extension; establishing window state data aligned to processor cache lines in the shared memory pages; and mapping the shared memory pages to the address space of a user-mode real-time process using a read-only shared mapping method. The window state data includes a window state identifier, a monotonically increasing sequence number, a real-time window start timestamp, and a current window end timestamp; configuring the target processor's local timer to end-time trigger mode; and setting the entry point of the corresponding interrupt vector as a raw interrupt handling entry point that bypasses standard kernel interrupts to enter and exit the framework. When an interrupt is triggered, the processor time counter is read to determine whether the current window should be entered as a real-time window or a non-real-time window. Based on the determination result, the window state data is updated, the task priority masking threshold is set, and the deadline corresponding to the next window switching time is loaded. During the execution of the raw interrupt handling entry point, the dynamic tick accounting of each processor is maintained independently, and the original timed interrupt path is triggered according to the preset interrupt cycle. The user-mode real-time thread sets hardware address monitoring for the cache line where the window state identifier is located. During the non-real-time window, a low-power wait with window deadline constraints is executed. After exiting the wait due to a shared memory page write, the window switching result is confirmed by combining the sequence number and the window state identifier, and the corresponding real-time workload is executed according to the real-time window start timestamp.

[0006] A second aspect of this application provides a real-time window switching device based on shared memory and hardware monitoring instructions, comprising: an allocation module, configured to allocate shared memory pages for a target processor in a general-purpose operating system kernel through a loadable kernel extension, establish window state data aligned to processor cache lines in the shared memory pages, and map the shared memory pages to the address space of a user-mode real-time process in a read-only shared mapping manner, wherein the window state data includes a window state identifier, a monotonically increasing sequence number, a real-time window start timestamp, and a current window end timestamp; and a setting module, configured to configure the target processor's local timer to end-time trigger mode, and set the entry point of the corresponding interrupt vector to a bare interrupt handling entry point that bypasses the kernel standard interrupt to enter and exit the framework, wherein the timer... When an interrupt is triggered, the processor time counter is read to determine whether the current window should be entered as a real-time window or a non-real-time window. Based on the determination result, the window state data is updated, the task priority masking threshold is set, and the deadline corresponding to the next window switching moment is loaded. The triggering module is used to independently maintain the dynamic tick accounting of each processor during the execution of the raw interrupt handling entry point, and trigger the original timed interrupt path according to the preset interrupt cycle. The execution module is used for the user-mode real-time thread to set the hardware address monitoring of the cache line where the window state identifier is located, to execute low-power wait with window deadline constraints during the non-real-time window, and after exiting the wait due to the shared memory page write, to confirm the window switching result by combining the sequence number and the window state identifier, and to execute the corresponding real-time workload according to the real-time window start timestamp.

[0007] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By allocating shared memory pages for the target processor within the general-purpose operating system kernel through loadable kernel extensions, window state data aligned to processor cache lines is established within these shared memory pages. These shared memory pages are then mapped to the address space of the user-mode real-time process using a read-only shared mapping. The window state data includes a window state identifier, a monotonically increasing sequence number, a real-time window start timestamp, and a current window end timestamp. The target processor's local timer is configured to end-time trigger mode, and the entry point of the corresponding interrupt vector is set as a raw interrupt handling entry point that bypasses standard kernel interrupts for entering and exiting the frame. When a timer interrupt is triggered, the processor time counter is read to determine the current entry point. The system can handle either real-time or non-real-time windows, updating window state data, setting task priority masking thresholds, and loading the deadline corresponding to the next window switch based on the determination result. During the execution of the raw interrupt handling entry point, it independently maintains dynamic tick accounting for each processor and triggers the original timed interrupt path according to the preset interrupt cycle. The user-mode real-time thread sets hardware address monitoring for the cache line where the window state identifier is located. During the non-real-time window period, it executes a low-power wait with window deadline constraints. After exiting the wait due to a shared memory page write, it confirms the window switch result by combining the sequence number and the window state identifier, and executes the corresponding real-time workload according to the real-time window start timestamp. This application can reduce window switch perception latency, improve real-time response determinism, and reduce system deployment and maintenance costs. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart illustrating the real-time window switching method based on shared memory and hardware monitoring instructions provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the real-time window switching device based on shared memory and hardware monitoring instructions provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] With the increasing demands for real-time performance in applications such as industrial control, robotics, and high-frequency trading, achieving microsecond-level deterministic scheduling on a general-purpose Linux operating system has become a key technological challenge. Existing technical solutions mainly fall into the following categories: 1. Signal-based real-time notification scheme In traditional Linux real-time solutions, the kernel notifies user-space threads to enter the real-time execution phase via signals or completions. This notification path requires traversing a complete interrupt handling framework: after a hardware interrupt is triggered, the process sequentially goes through `irq_enter()` to enter the interrupt context, executes the interrupt handler function, `irq_exit()` to exit the interrupt context and trigger soft interrupt (softirq) handling, the scheduler checks for preemption, the signal is delivered to the target process, and the user-space signal handler function is executed. The cumulative latency of this complete path is typically in the range of 5-50 microseconds and fluctuates significantly with system load.

[0013] 2. PREEMPT_RT Full Preemption Scheme The PREEMPT_RT patch reduces scheduling latency by transforming the Linux kernel into a fully preemptive kernel. This approach requires extensive modifications to the kernel source code, threading interrupt handlers and replacing spinlocks with preemptible mutexes. While it can reduce worst-case latency to the order of 10-50 microseconds, it still relies on the Linux scheduler for task switching and cannot overcome the scheduler's own overhead bottleneck.

[0014] 3. Dual-kernel architecture solution (Xenomai / RTAI) Dual-kernel solutions like Xenomai introduce a separate real-time kernel (I-pipe or Dovetail interrupt pipeline) under Linux, with real-time tasks running in an independent out-of-band (OOB) domain. This solution can achieve latency in the 1-5 microsecond range, but it requires patching the Linux kernel, resulting in high deployment and maintenance costs. Furthermore, the real-time code must use the dedicated Xenomai API and cannot directly use the standard POSIX interface.

[0015] 4. Hardware isolation solution (Jailhouse) Virtualization-based solutions like Jailhouse completely isolate the physical CPU core from Linux control, running bare-metal real-time tasks on the isolated core. While this achieves sub-microsecond latency, the real-time tasks are completely isolated from the Linux environment, making it impossible to use Linux infrastructure such as file systems and network protocol stacks, resulting in difficulties in development and debugging.

[0016] The common drawbacks of the existing solutions mentioned above are that they either rely on the Linux interrupt handling framework and scheduler (introducing unavoidable latency overhead), require modification of the kernel source code (making deployment and maintenance difficult), or isolate real-time tasks outside the Linux environment (losing the convenience of a general-purpose operating system).

[0017] In particular, the overhead of the Linux interrupt handling framework itself is a fundamental bottleneck. The standard interrupt handling path includes: irq_enter() updating the preemption counter and time accounting, execution of the interrupt handler function, and irq_exit() checking and executing pending soft interrupts (including timer soft interrupt TIMER_SOFTIRQ, scheduler soft interrupt SCHED_SOFTIRQ, RCU soft interrupt RCU_SOFTIRQ, etc.). The framework overhead for each interrupt is approximately 1-5 microseconds. For real-time window switching scenarios with a period of 1 millisecond, the framework overhead of two window switches per cycle (NRT to RT and RT to NRT) accounts for a significant proportion, severely limiting the achievable real-time accuracy.

[0018] Therefore, the technical problem to be solved by this application is: how to eliminate the interrupt framework overhead and scheduler latency in the real-time window switching notification from kernel to user space without modifying the Linux kernel source code or isolating the real-time task from the Linux environment, and achieve a window switching perceived latency of sub-microsecond level (less than 1 microsecond).

[0019] In view of the problems existing in the prior art, this application proposes a method for realizing sub-microsecond window switching awareness for user-mode real-time tasks on a general-purpose Linux operating system. Addressing the issue that the kernel-to-user-mode notification path must pass through multiple levels of latency (cumulative 5-50 μs) including interrupt framework, soft interrupt handling, scheduler wake-up, and signal delivery, this application employs a synergistic combination of the following three key technologies: First, the shared memory direct notification mechanism. The kernel allocates a page of physical memory and maps it to the user-mode process address space in read-only mode. The naked interrupt service routine (ISR) triggered by the LAPIC TSC-Deadline timer directly writes the window status fields (including the current window type, RT window start timestamp, and end timestamp) into the interrupt context, without going through the Linux standard interrupt framework (irq_enter / irq_exit), without triggering soft interrupts or clock tick processing, and without involving any system calls.

[0020] Second, x86 hardware monitoring instructions achieve zero-overhead waiting. User-space threads use the UMONITOR instruction to set up hardware-level monitoring of the cache line containing the shared memory window state field, and then enter the processor's low-power monitoring state via the UMWAIT instruction. When the ISR writes to shared memory, triggering the cache coherence protocol to update the cache line, UMWAIT automatically exits within nanoseconds, and the user thread immediately reads the shared memory confirmation window state and performs real-time work. The entire awareness path does not require polling to consume CPU resources, nor does it require the kernel scheduler to participate.

[0021] Third, the raw interrupt service routine eliminates framework overhead. The ISR entry point uses compiler-defined raw function attributes, manually managing the saving and restoring of all 15 general-purpose registers. The C language processing function only performs four operations: shared memory write, task priority register setting, interrupt descriptor table switching, and TSC-Deadline timer reloading. Through a two-level indirect symbol resolution technique (first using a kernel probe to obtain the address of the symbol lookup function, and then using that function to find the RCU trace function located in the non-instrumentable code segment), the correctness of the RCU dynamic clock accounting is maintained independently, enabling the raw ISR and the Linux RCU subsystem to coexist safely.

[0022] Experimental results show that this method achieves a window switching latency of approximately 329 nanoseconds from ISR triggering to user-space thread awareness on the Intel Atom x6425RE platform. The window switching itself incurs an overhead of approximately 200 nanoseconds, and the P99.9 jitter is less than 3.5 microseconds. In 3.6 million consecutive iterations, the anomaly rate (>5μs) is only 2.5 parts per million. Compared to traditional signal notification schemes (~5μs) and kernel scheduler wake-up schemes (~5-50μs), the latency is reduced by more than an order of magnitude.

[0023] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0024] Figure 1This is a flowchart illustrating the real-time window switching method based on shared memory and hardware monitoring instructions provided in an embodiment of this application. Figure 1 As shown, the method may specifically include: S101 allocates shared memory pages for the target processor in the general operating system kernel through loadable kernel extensions, establishes window state data aligned to processor cache lines in the shared memory pages, and maps the shared memory pages to the address space of the user-mode real-time process in a read-only shared mapping manner. The window state data includes window state identifier, monotonically increasing sequence number, real-time window start timestamp, and current window end timestamp. S102, configure the local timer of the target processor to the deadline trigger mode, and set the entry of the corresponding interrupt vector to the raw interrupt handling entry for bypassing the kernel standard interrupt to enter and exit the frame. When the timer interrupt is triggered, read the processor time count, determine whether to enter the real window or the non-real window, and update the window state data, set the task priority masking threshold and load the deadline corresponding to the next window switching time according to the determination result. S103, during the execution of the raw interrupt handling entry point, independently maintains the dynamic tick accounting for each processor, and triggers the original timed interrupt path according to the preset interrupt cycle; S104, the user-mode real-time thread sets hardware address monitoring for the cache line where the window state identifier is located, performs low-power wait with window deadline constraints during non-real-time window periods, exits the wait due to shared memory page write, confirms the window switching result by combining the sequence number and window state identifier, and executes the corresponding real-time workload according to the real-time window start timestamp.

[0025] In some embodiments, allocating shared memory pages for a target processor within a general-purpose operating system kernel via a loadable kernel extension includes: When a user-mode real-time process is registered, a physical page is allocated to the target processor and a kernel address mapping of the physical page is established, thus associating the user-mode real-time process with the target processor. Perform initialization processing on the physical page, and construct window state data in the physical page according to the processor cache line alignment rules; In response to a memory mapping request initiated by a user-mode real-time process, the system identifies the mapping request for a shared memory page based on a preset mapping identifier and inserts the physical page into the virtual address region corresponding to the user-mode real-time process. Set the inserted physical page to a read-only shared mapping so that the user-mode real-time process can read window state data based on the shared memory page.

[0026] Specifically, this application's implementation of allocating shared memory pages for the target processor within a general-purpose operating system kernel through a loadable kernel extension is not simply providing a regular shared memory block for user-mode programs. Instead, it constructs a shared state channel, centered around real-time window switching scenarios, that updates the window state from the kernel side to direct reading by the user mode. This shared state channel is maintained by the loadable kernel extension within the kernel execution context corresponding to the target processor and establishes a one-to-one correspondence with the real-time user-mode process. This ensures that the window state identifier, sequence number, and timestamp information written at subsequent raw interrupt handling entry points can be directly perceived by the real-time user-mode process. Accordingly, the shared memory page in this embodiment serves both as a window state carrier and a read-only shared mapping between kernel mode and user mode. Its establishment process includes physical page allocation, kernel address mapping establishment, window state data initialization, user-mode mapping request identification, and read-only shared mapping attribute setting.

[0027] In this embodiment, the window state data in the shared memory page is preferably organized according to the processor cache line alignment rules. This is because the user-mode real-time thread subsequently monitors the cache line containing the window state identifier via hardware address monitoring instructions. If related fields span multiple cache lines, it can easily introduce additional cache consistency overhead or false sharing issues. Therefore, this embodiment centrally arranges the window state data within the same cache line and includes at least the window state identifier, a monotonically increasing sequence number, a real-time window cutoff timestamp, a non-real-time window cutoff timestamp, and a real-time window start timestamp. The window state identifier indicates whether the current window is real-time or non-real-time; the monotonically increasing sequence number is used to perform two consistency checks when reading multiple fields in user mode, avoiding data inconsistencies caused by window switching during the reading process; and each timestamp field provides the user-mode thread with window boundaries and a benchmark for real-time load execution.

[0028] In a specific example, on an Intel x86-64 processor platform with a Linux 5.15 kernel, loadable kernel extensions can be implemented as kernel modules. For instance, when a user-mode real-time process initiates a registration request via a device file, the kernel module first records the task structure reference corresponding to that user-mode real-time process and establishes an association between it and the target processor according to a preset binding strategy. This association can be maintained using a per-processor context structure, that is, recording the user-mode real-time process identifier, the shared memory page object, and the kernel virtual address corresponding to the shared memory page in the context corresponding to the target processor. Subsequently, the kernel module calls the page allocation mechanism to allocate a physical page for the target processor and directly performs zeroing initialization during allocation, so that the allocated page is in an initial state where window state data can be directly written. Preferably, a page allocation method with zero-padding attributes can be used to reduce the overhead of subsequent explicit zeroing.

[0029] After acquiring the physical page, the kernel module further establishes a kernel address mapping for that physical page and writes the initial content of the window state data into the shared memory page through this kernel address mapping. For example, the window state identifier can be initialized to the value corresponding to the non-real-time window, the monotonically increasing sequence number can be initialized to zero, and each cutoff timestamp and the real-time window start timestamp can be initialized to zero or the baseline count value of the startup phase. At the same time, the kernel module organizes the positions of the above fields according to the 64-byte cache line boundaries, so that the window state identifier and the timestamp field are in the same cache line, thereby providing a unified data access object for subsequent raw interrupt handling entry writing and user-mode hardware monitoring waiting.

[0030] When a user-mode real-time process subsequently initiates a memory mapping request, the kernel module does not process all memory mapping requests indiscriminately. Instead, it first identifies whether the request is for a shared memory page based on a preset mapping identifier. In a specific example, the preset mapping identifier can be set to a predefined page offset identifier. When the user-mode real-time process calls the memory mapping system call, it carries this page offset identifier. The kernel module reads the page offset parameter of the corresponding virtual address region in the memory mapping processing function and determines whether the current request is a shared memory page mapping request. If the identification is successful, the aforementioned physical page is inserted into the virtual address region corresponding to the user-mode real-time process, and the virtual address region is set with a read-only shared mapping attribute and a non-extensible attribute. By setting the mapping attribute to read-only, it ensures that the user-mode real-time process only has the permission to read window state data, but not the permission to reverse-modify the content of the shared memory page, thereby avoiding user-mode accidental writes that could cause distortion of the kernel-side window state.

[0031] For example, in a specific test case, after a user-mode real-time process registers via the device file, it initiates a memory mapping request of one page size, carrying the page offset magic number in the request parameters. After the kernel module recognizes this page offset magic number, it inserts the previously allocated shared memory physical page into the virtual address region of the user-mode real-time process. Once the user-mode real-time process completes the mapping, it can directly read fields such as the window state identifier, monotonically increasing sequence number, and real-time window start timestamp within its address space. Subsequently, when the raw interrupt handler performs window switching on the target processor, it can directly write new window state data to this shared memory page. The user-mode real-time process does not need to obtain window switching information through signals, completion variables, or system calls, thus making the shared memory page the direct carrier of real-time window switching information.

[0032] Through the above method, this embodiment completes the entire process of shared memory page allocation from kernel allocation and data initialization to user-space read-only shared mapping, establishing a stable association between the target processor, user-space real-time processes, and shared memory pages. This provides a directly accessible data foundation for subsequent low-latency window switching awareness based on hardware monitoring instructions. This implementation reduces the intermediate processing steps for transferring kernel-side state to user space, improving the consistency and timing matching of window state readings.

[0033] In some embodiments, window state data aligned to processor cache lines is established in shared memory pages, and the shared memory pages are mapped to the address space of user-mode real-time processes using a read-only shared mapping, including: Perform zeroing initialization on the shared memory page and build a window state data area in the shared memory page that is aligned with the boundaries of the individual processor cache lines; In the window state data area, set the window state identifier field, the monotonically increasing sequence number field, the real-time window start timestamp field, the real-time window end timestamp field, and the non-real-time window end timestamp field so that the window state switching information and the corresponding timing information are stored in the same cache line range. In response to a shared mapping request initiated by a user-mode real-time process, the mapping object for the shared memory page is identified according to a preset page offset identifier, and the shared memory page is inserted into the virtual address region corresponding to the user-mode real-time process. Set the read-only shared mapping attribute for the virtual address region so that the user-mode real-time process can directly read the window state identifier field, the monotonically increasing sequence number field, and the timestamp field without modifying the window state data.

[0034] Specifically, this application establishes window state data aligned to processor cache lines in shared memory pages and maps the shared memory pages to the address space of user-mode real-time processes using a read-only shared mapping method. This approach is designed around the technical chain of "kernel-side window state writing—user-mode thread direct reading—hardware monitoring cache line wake-up". Since the subsequent user-mode real-time thread monitors the cache line containing the window state identifier through hardware address monitoring instructions, the key state fields in the shared memory pages are not arbitrarily scattered, but are centrally organized within the boundary of a single processor cache line. This reduces the additional consistency overhead caused by cross-cache line access and avoids interference from false sharing on the window switching perceived latency.

[0035] In this embodiment, after allocating a shared memory page to the target processor, the loadable kernel extension first performs a zeroing initialization process on the shared memory page. Specifically, on an Intel x86-64 processor platform with a Linux 5.15 kernel, a physical page can be directly allocated using the page allocator, and the initial content of the page can be zeroed out using an allocation method with zero-padding attributes. Subsequently, a window state data area is established in the shared memory page using the kernel virtual address corresponding to the physical page. The window state data area is preferably aligned to 64-byte cache line boundaries, and key fields are concentrating within the same cache line.

[0036] Furthermore, the window state data area includes at least a window state identifier field, a monotonically increasing sequence number field, a real-time window start timestamp field, a real-time window end timestamp field, and a non-real-time window end timestamp field. The window state identifier field indicates whether the window is currently in a real-time or non-real-time window; the monotonically increasing sequence number field performs two consistency checks when multiple fields are read in user mode to avoid field mismatches caused by raw interrupt handling entry points updating shared memory pages during the read process; the real-time window start timestamp field provides a starting execution benchmark for real-time workloads for user-mode real-time threads; and the real-time window end timestamp field and the non-real-time window end timestamp field identify the processor time count corresponding to the current or next window boundary, respectively. In a specific structure example, the window state identifier field can be located at offset 0, the monotonically increasing sequence number field at offset 4, the real-time window end timestamp field at offset 8, the non-real-time window end timestamp field at offset 16, and the real-time window start timestamp field at offset 48, thus centrally storing window state switching information and corresponding timing information in the same cache line.

[0037] After the window state data area is constructed, a kernel extension can be loaded to continue maintaining the mapping relationship between the shared memory page and the user-mode real-time process. Specifically, after registration, the user-mode real-time process initiates a shared mapping request, preferably for a page size. To enable the kernel extension to distinguish shared memory page mapping requests from ordinary device mapping requests, this embodiment uses a preset page offset identifier to identify the mapping object. In a specific example, the user-mode real-time process can carry a predefined page offset magic number in the memory mapping system call and initiate a mapping request in read-only, shared mode. The kernel extension reads the page offset parameter corresponding to the virtual address region in its memory mapping processing function. When the page offset parameter matches the preset page offset identifier, the current mapping object is identified as a shared memory page.

[0038] After identifying the mapping object for the shared memory page, the kernel extension inserts the shared memory page into the virtual address region corresponding to the user-mode real-time process. Specifically, a page insertion mechanism can be used to add the physical page to the user-mode real-time process's page table, and a read-only shared mapping attribute can be set for the corresponding virtual address region. Building upon the previous example, this virtual address region can be further configured to be non-expandable and non-dumpable to prevent expansion or abnormal dumping in user mode, thereby improving the stability and boundary constraints during the use of the shared state page. By setting the virtual address region to a read-only shared mapping, the user-mode real-time process only has the permission to directly read window state data, but not the permission to modify the window state identifier field, the monotonically increasing sequence number field, and the timestamp fields. This avoids window state distortion caused by user-mode write errors.

[0039] In a specific example, after the user-mode real-time process registers via the device file, it calls the memory mapping interface, setting the page length to 4096 bytes, access permissions to read-only, and mapping mode to shared mapping in the request parameters, and carrying a preset page offset magic number in the page offset parameter. Upon receiving this shared mapping request, the kernel extension confirms that the request targets a shared memory page, and then inserts the previously allocated and cache-aligned shared memory page into the virtual address region of the user-mode real-time process. After successful mapping, the user-mode real-time process can directly read the window status identifier field, the monotonically increasing sequence number field, the real-time window start timestamp field, the real-time window end timestamp field, and the non-real-time window end timestamp field. Subsequently, when the raw interrupt handler performs window switching on the target processor, the writes to the fields in the shared memory page can be monitored by the user-mode real-time thread through the processor cache coherency mechanism, thus providing a direct data basis for subsequent low-power wait-to-exit and window switching confirmation.

[0040] Through the above implementation, this embodiment establishes a window state data area aligned with the boundary of a single processor cache line within the shared memory page. This shared memory page is stably mapped to the user-mode real-time process address space using a read-only shared mapping method, enabling the window state identifier field, monotonically increasing sequence number field, and timestamp field to be directly read by the user-mode real-time process. This implementation reduces cross-cache line access interference, improves the consistency and timing matching of window state readings, and provides a reliable data foundation for subsequent real-time window switching awareness based on hardware address monitoring and low-power waiting.

[0041] In some embodiments, the target processor's local timer is configured to a deadline-triggered mode, and the entry point of the corresponding interrupt vector is set as a raw interrupt handling entry point that bypasses the kernel's standard interrupt entry and exit framework, including: Configure the local timer register of the target processor to perform mode configuration, set the local timer to a timer interrupt source triggered based on the processor time count cutoff value, and write the cutoff time corresponding to the first window switching time into the cutoff time register; Assign a preset high-priority interrupt vector to the timer interrupt source. The high-priority interrupt vector is higher than the maskable interrupt priority class corresponding to the task priority masking threshold during the real-time window. A raw interrupt handling entry point is constructed, which adopts raw function declaration and uninstrumented declaration, and implements interrupt source privilege level judgment, segment base address register switching, general-purpose register saving and processing context passing through inline assembly. The interrupt descriptor table entry corresponding to the high-priority interrupt vector is updated to point to the raw interrupt handling entry. After the window switching process is completed at the raw interrupt handling entry, the general-purpose register is restored, the segment base address register is restored, and the interrupt is returned via inline assembly.

[0042] Specifically, this application configures the target processor's local timer to deadline-triggered mode and sets the entry point of the corresponding interrupt vector as a raw interrupt handling entry point that bypasses the kernel's standard interrupt entry and exit framework. This is the key foundation for achieving low-latency triggering of real-time window switching. The implementation of this part of the technical solution does not follow the standard timer interrupt handling path of the general-purpose operating system kernel. Instead, a loadable kernel extension directly takes over the window switching triggering function of the target processor's local timer and establishes a dedicated interrupt entry point for real-time window switching in the target processor's interrupt descriptor table. This allows subsequent window state writing, task priority masking threshold adjustment, and the next deadline loading to be completed without going through the standard interrupt framework.

[0043] In this embodiment, the local timer is preferably a local timer in the target processor's local advanced programmable interrupt controller and configured as a timer interrupt source triggered based on the processor time count cutoff value. This is because the cutoff trigger mode can directly use the processor timestamp counter as the timing reference, thus avoiding the accumulation of errors caused by cycle count conversion and facilitating the direct conversion of the real-time window start and end times into the corresponding cutoff time values. Specifically, on an Intel x86-64 processor platform and in a Linux 5.15 kernel environment, when initializing the target processor's real-time window switching mechanism, the loaded kernel extension first reads the local vector table register corresponding to the local timer and reconfigures its mode bit to operate in cutoff trigger mode. Then, based on the preset window period and the initial window switching plan, it determines the processor time count corresponding to the first window switching time and writes this cutoff time into the cutoff time register, so that the local timer triggers the window switching interrupt at the corresponding time.

[0044] To ensure that timer interrupts can still be received and delivered by the processor during the real-time window, this embodiment also assigns a high-priority interrupt vector to the timer interrupt source. This high-priority interrupt vector is higher than the maskable interrupt priority class masked by the task priority masking threshold during the real-time window. Referring to the specific examples in the preceding embodiments, the interrupt vector can be set to a predefined system-reserved vector number and placed in priority class 15. This ensures that even when the task priority register is set to mask priority classes 0 to 14 during the real-time window, the timer interrupt can still penetrate the current masking threshold and arrive on time. This guarantees that the transition between the end of the real-time window and the start of the next non-real-time window will not be blocked by ordinary device interrupt handling strategies.

[0045] After establishing a dedicated interrupt trigger source, this embodiment further constructs a raw interrupt handling entry point. This raw interrupt handling entry point is not a regular kernel function, but a dedicated entry point jointly defined by a raw function declaration and a declaration without instrumentation. The raw function declaration prevents the compiler from automatically generating function prologue and function epilogue code, ensuring that the stack layout at the interrupt entry point is entirely controlled by inline assembly. The declaration without instrumentation prevents the compiler from inserting trace probe call instructions at the function entry point, avoiding disruption of the predetermined offset relationship of the interrupt return frame due to additional stack push operations. This setting is particularly important for subsequently determining the privilege level of the interrupt source based on the code segment registers in the interrupt return frame.

[0046] Furthermore, the raw interrupt handling entry point uses inline assembly to complete the interrupt source privilege level determination, segment base address register switching, general-purpose register saving, and processing context passing. In specific implementation, the privilege level bit corresponding to the code segment register in the interrupt return frame is first checked to determine whether the current interrupt originates from user mode or kernel mode. If the determination indicates that the interrupt originates from user mode, a segment base address register switching instruction is executed to switch to the segment base address context required by kernel mode. Subsequently, all general-purpose registers are pushed onto the stack according to a preset saving order, and the current stack pointer is passed as a parameter to the subsequent window switching handling function. In a specific example, the general-purpose registers may include 15 general-purpose registers, saved in a fixed order, so that subsequent handling functions can access the register contents in the interrupted context according to the preset register frame structure.

[0047] After completing the window switching process, the raw interrupt handling entry point still needs to complete the exit path processing through inline assembly. Specifically, this includes: restoring all general-purpose registers in the reverse order of saving; determining the privilege level of the interrupt source based on the code segment registers in the interrupt return frame; if the original interrupt source is user mode, performing the corresponding segment base address register restoration operation; and finally, executing the interrupt return instruction to return to the interrupted context and continue execution. In this way, the entire interrupt entry and exit path do not depend on the standard interrupt entry and exit functions of the general-purpose operating system kernel.

[0048] In a specific example, when the loadable kernel extension initiates the real-time window switching function on the target processor, it first saves the original local timer vector configuration, then switches the target processor's local timer to deadline-triggered mode and sets the interrupt vector to a preset high-priority vector. Subsequently, it updates the entry address of the corresponding entry in the target processor's interrupt descriptor table, making it point to the aforementioned raw interrupt handling entry. When the deadline arrives, the processor directly jumps to this raw interrupt handling entry, which performs privilege level checks, segment base address register switching, and saving of 15 general-purpose registers through inline assembly, before calling the window switching processing logic. After processing, it restores the registers sequentially and executes the interrupt return. Therefore, subsequent shared memory page writes, task priority masking threshold adjustments, and the next deadline reload are all based on this dedicated interrupt entry.

[0049] Through the above implementation, this embodiment establishes a dedicated timer interrupt source based on a deadline-triggered mode and a raw interrupt processing entry that bypasses the standard interrupt framework on the target processor side. This enables real-time window switching triggering to be completed directly based on processor time counting, and ensures that the timer interrupt remains reachable during the real-time window. This implementation reduces the interference of standard interrupt entry, exit, and associated instrumentation on the interrupt path, improves the timing accuracy and processing path controllability of window switching triggering, and provides a stable kernel-side triggering foundation for subsequent window state updates and rapid awareness by user-mode real-time threads.

[0050] In some embodiments, when a timer interrupt is triggered, the processor time counter is read to determine whether the current window should be entered (real-time or non-real-time), and the window state data is updated, the task priority masking threshold is set, and the deadline for loading the next window switching time is set according to the determination result, including: In the processing corresponding to the raw interrupt handling entry point, the current processor time count is read, and the target window type is determined by combining the current window cutoff timestamp and the preset window switching order; When the target window type is a real-time window, write the real-time window identifier, the real-time window start timestamp, and the real-time window end timestamp, increment the monotonically increasing sequence number, adjust the task priority masking threshold to a masking threshold that only allows high-priority interrupt vectors to penetrate, and load the end time corresponding to the end time of the real-time window. When the target window type is a non-real-time window, write the non-real-time window identifier and the non-real-time window deadline timestamp, increment the monotonically increasing sequence number, restore the task priority masking threshold, and load the deadline time corresponding to the start time of the next real-time window.

[0051] Specifically, this application reads the processor time counter when a timer interrupt is triggered, determines whether to enter a real-time window or a non-real-time window, and updates the window state data, sets the task priority masking threshold, and loads the deadline corresponding to the next window switching time based on the determination result. This is the core execution link in the entire real-time window switching chain. This link is completed by the processing function corresponding to the aforementioned raw interrupt handling entry point. It does not execute according to the conventional timer interrupt handling method of a general operating system kernel, but bypasses the standard interrupt entry and exit framework, and directly performs window type determination and state writing based on the current processor time counter, the current window deadline timestamp, and the preset window switching order. As a result, the window switching-related state updates, the loading of the next deadline, and the adjustment of the task priority masking threshold can be completed continuously in the same processing context, thereby ensuring the timing consistency of window boundary switching.

[0052] In this embodiment, the so-called preset window switching order refers to the switching rules pre-established for the sequential relationship between real-time windows and non-real-time windows within a period. For example, in a window scheduling scenario with a period of 1000 microseconds, it can be pre-set that in each period, the real-time window is entered first, and then the non-real-time window is switched to, with the current window's expiration timestamp indicating the end boundary of the current stage. The so-called task priority masking threshold refers to a threshold control parameter that restricts the priority class of maskable interrupts through the target processor's task priority register. In this application, after entering the real-time window, the task priority masking threshold needs to be raised to a state that only allows high-priority interrupt vectors to pass through, in order to reduce the interference of ordinary device interrupts on the execution of real-time workloads; after entering the non-real-time window, the task priority masking threshold is restored, so that the system regains its normal device interrupt reception capability. In addition, the monotonically increasing sequence number is used to characterize the number of times the window state data is updated, and it is incremented once with each window switch, so that the user-mode real-time thread can perform consistency checks when reading multiple fields.

[0053] With a specific example, on an Intel x86-64 processor platform and in a Linux 5.15 kernel environment, a kernel extension can be loaded to configure the target processor's local timer to TSC-Deadline mode, and the window switching logic can be executed by the C language processing function at the raw interrupt handling entry point. In the specific implementation, after each timer interrupt is triggered, the processing function first reads the current processor time count, i.e., reads the current timestamp counter value, and then combines this with the current window cutoff timestamp stored in the shared memory page to determine whether the current window start boundary or the non-real-time window start boundary has been reached.

[0054] If the preset window switching order determines that the current window should be entered as a real-time window, the processing function writes the real-time window identifier to the window state data area in the shared memory page, writes the currently read processor time count to the real-time window start timestamp field, and calculates the processor time count corresponding to the real-time window end time based on the window configuration of the current period, and writes it to the real-time window end timestamp field. After completing the above field writing, the monotonically increasing sequence number is incremented to create a new state version for this window state write.

[0055] Furthermore, when the target window type is a real-time window, the processing function also adjusts the task priority masking threshold. Referring to the specific example in the preceding embodiments, the task priority register can be set to 0xE0 to mask all device interrupts of priority classes 0 to 14, allowing only the priority class containing the high-priority interrupt vector to be received by the processor. Subsequently, the processing function writes the corresponding deadline time into the deadline time register based on the real-time window's end boundary within the current cycle, causing the local timer to trigger a timer interrupt again when the real-time window ends, thus entering the next window type determination process.

[0056] If the processing function determines that it should enter a non-real-time window based on the current processor time count, the current window cutoff timestamp, and the preset window switching order, it writes a non-real-time window identifier to the window state data area in the shared memory page, updates the non-real-time window cutoff timestamp field according to the end boundary of the next non-real-time interval, and increments the monotonically increasing sequence number. Then, it restores the task priority masking threshold, allowing the target processor to re-allow interrupt delivery from ordinary devices. Combining this with the previous example, the task priority register can be restored to its original value saved before startup, such as 0x10. Finally, based on the processor time count corresponding to the start time of the next real-time window, the cutoff time register is reloaded to ensure that the local timer triggers an interrupt precisely at the start boundary of the next real-time window.

[0057] For example, in a specific test case, the window period is set to 1000 microseconds, and the real-time window ratio is set to 80%. When the local timer triggers an interrupt at the start of the period, the processing function reads the current timestamp counter value, determines that it has entered the real-time window, writes the window state identifier as the real-time window, writes the processor time count corresponding to that moment into the real-time window start timestamp field, calculates the real-time window end boundary 800 microseconds later as the new real-time window cutoff timestamp, increments the monotonically increasing sequence number, sets the task priority register to 0xE0, and writes the cutoff time 800 microseconds later into the cutoff time register. When the cutoff time is reached and another interrupt is triggered, the processing function determines that it should switch to a non-real-time window, writes the non-real-time window identifier and the non-real-time window cutoff timestamp, increments the monotonically increasing sequence number, restores the original value of the task priority register, and reloads the cutoff time corresponding to the start of the next period into the cutoff time register. After executing in a loop in the above manner, the user-mode real-time thread can accurately identify the window boundary and start the real-time workload based on the updated window state identifier, real-time window start timestamp, and various cutoff timestamps in the shared memory page.

[0058] Through the above implementation, this embodiment achieves continuous execution of window type determination, window state data update, task priority masking threshold adjustment, and loading at the next window switching moment in the processing corresponding to the raw interrupt handling entry point. This enables real-time windows and non-real-time windows to switch stably in a preset order, and keeps the window state information in the shared memory page synchronized with the actual window stage of the target processor. This implementation helps reduce intermediate scheduling links in the window switching processing chain, improves the timing accuracy of window state updates, and enhances the consistency of user-mode real-time thread awareness of window switching.

[0059] In some embodiments, during the execution of the raw interrupt handling entry point, a dynamic tick accounting per processor is maintained independently, and the original timed interrupt path is triggered according to a preset interrupt cycle, including: In the processing corresponding to the raw interrupt handling entry, the interrupt entry accounting function is called before the window switching process and the interrupt exit accounting function is called after the window switching process to perform independent updates to the dynamic tick count corresponding to the current processor. The interrupt entry accounting function and the interrupt exit accounting function are not triggered by the kernel standard interrupt entry and exit framework. The function addresses of interrupt entry and exit accounting functions are obtained through a two-level indirect symbol resolution method. The two-level indirect symbol resolution method includes: obtaining the address of the kernel symbol lookup function based on kernel probe points, and finding the addresses of interrupt entry and exit accounting functions based on the kernel symbol lookup function. In the processing corresponding to the raw interrupt handling entry, an interrupt cycle counter is maintained. When the interrupt cycle counter reaches the preset number of cycles, an inter-processor interrupt is sent to the original timer interrupt vector, and the interrupt cycle counter is reset after the original timer interrupt path is triggered.

[0060] Specifically, this application independently maintains dynamic tick accounting for each processor during the execution of the raw interrupt handling entry point and triggers the original timer interrupt path according to a preset interrupt cycle. This is a supporting processing mechanism set up to ensure the continued normal operation of related subsystems of the general operating system kernel, based on the aforementioned dedicated interrupt link for real-time window switching. Since the window switching processing in this application is directly completed by the raw interrupt handling entry point and does not go through the kernel standard interrupt entry and exit framework, the dynamic tick accounting, read-only copy update state advancement, and scheduler clock tick and timer processing mechanisms in the kernel that rely on the standard interrupt path cannot naturally detect the occurrence and exit of this interrupt. Therefore, in the processing corresponding to the raw interrupt handling entry point, this embodiment combines window switching processing with independent dynamic tick accounting and keeping the original timer interrupt path alive, so that the target processor can still maintain the continuous operation of the kernel basic subsystem after taking over the local timer window switching function.

[0061] In this embodiment, the so-called dynamic tick count refers to the interrupt entry and exit state count maintained at the processor level, used to characterize whether the current processor is in an interrupt context that can be recognized by the kernel's read-only copy update subsystem. If the raw interrupt handling entry point bypasses the standard interrupt entry and exit framework for an extended period, the dynamic tick count cannot be updated synchronously, and the kernel will mistakenly judge that the target processor has not undergone the corresponding state change for a long time, thus triggering a pause alarm after a long period of operation. The so-called interrupt entry accounting function and interrupt exit accounting function refer to kernel functions used to update the dynamic tick count at the start and end of interrupt handling, respectively. Since this application does not trigger these two types of functions through the kernel's standard interrupt entry and exit framework, but is instead independently called by the processing function corresponding to the raw interrupt handling entry point before and after window switching, the update of the dynamic tick count, window state writing, task priority masking threshold adjustment, and deadline loading are continuous operations in the same raw interrupt handling chain.

[0062] In a specific example, on an Intel x86-64 processor platform with a Linux 5.15 kernel, after the kernel module initialization is complete, the function addresses of the interrupt entry and exit accounting functions are first obtained through a two-level indirect symbol resolution method. This is because, in Linux 5.15 and later versions, the relevant accounting functions are located in non-instrumentable code segments and are not directly exported as module-usable symbols, making them impossible for kernel modules to directly reference or register directly to the function entry point using ordinary kernel probe points. Therefore, this embodiment preferably constructs the first-level address resolution process first, that is, registering probe points on the kernel symbol lookup function based on the kernel probe point mechanism.

[0063] Since the kernel symbol lookup function is not located in a non-instrumentable code segment, the probe point registration check passes. After successful registration, the function address field in the probe point structure is read to obtain the address of the kernel symbol lookup function, and the probe point is immediately unregistered. Then, the second-level address resolution process begins, which involves calling the previously obtained kernel symbol lookup function to find the addresses of the interrupt entry and exit accounting functions, respectively, and saving the found addresses as function pointers for indirect calling by the corresponding handler function at the raw interrupt handling entry point.

[0064] Furthermore, after obtaining the aforementioned function addresses, the processing function corresponding to the raw interrupt handling entry point first calls the interrupt entry accounting function each time a local timer interrupt is triggered. Then, it performs window type determination, window state data update, task priority masking threshold adjustment, and loading of the deadline corresponding to the next window switching time. After completing the window switching process, it calls the interrupt exit accounting function. In this way, the entry and exit updates of the dynamic tick counter occur synchronously with the window switching process, but without triggering soft interrupt handling and scheduler checks, thus maintaining the independence of the dedicated window switching path in this application.

[0065] Furthermore, in some embodiments, to ensure that target processors not isolated by processor isolation parameters can still maintain their original timer interrupt paths, this embodiment also maintains an interrupt cycle counter in the processing corresponding to the raw interrupt handling entry point. This interrupt cycle counter can be decremented once after each raw interrupt handling process or incremented once after each window switch; when it reaches a preset number of cycles, an inter-processor interrupt is sent to the original timer interrupt vector, and the interrupt cycle counter is reset after triggering the original timer interrupt path. For example, if the interrupt cycle at the raw interrupt handling entry point is set to 100 microseconds, the preset number of cycles can be set to 10, causing the inter-processor interrupt to be sent to the original timer interrupt vector at a frequency of once every 1 millisecond. This inter-processor interrupt is received by the processor after returning from the raw interrupt handling entry point, which then triggers the kernel's original timer interrupt handler to execute along the standard interrupt path, advancing scheduler clock ticking, timer processing, and read-only copy update-related callbacks. Simultaneously, before sending the inter-processor interrupt, the original local timer vector number can be pre-saved to ensure that the inter-processor interrupt is accurately delivered to the vector corresponding to the original timer interrupt path.

[0066] For example, in a specific test case, the target processor does not have processor isolation parameters set. After the kernel module takes over the local timer, in the processing corresponding to each raw interrupt handling entry, it first calls the interrupt through a function pointer to enter the accounting function, completing the entry update of the current processor's dynamic tick count; then it performs the switching processing between real-time and non-real-time windows; before exiting the window switching processing, it calls the interrupt through a function pointer to exit the accounting function; and simultaneously maintains the interrupt cycle counter. When the counter accumulates to 10 interrupt cycles, it sends an inter-processor interrupt to the original timer interrupt vector saved during system startup, and then resets the counter and starts counting again. After running in this way, even if the window switching on the target processor is mainly handled by the raw interrupt handling entry, the kernel's original scheduler clock tick and timer processing can still be periodically activated according to the preset rhythm.

[0067] Through the above implementation, this embodiment achieves independent maintenance of the dynamic tick count and periodic keep-alive of the original timer interrupt path in the processing corresponding to the raw interrupt handling entry point. This allows the target processor to maintain the normal operation of kernel read-only copy update state progression, scheduler clock ticking, and timer processing even after using a dedicated window to switch interrupt links. This implementation helps avoid pause alarms during long-term operation and improves the compatibility and continuous operational stability between the real-time window switching mechanism and general operating system kernel subsystems.

[0068] In some embodiments, the user-mode real-time thread sets hardware address monitoring for the cache line containing the window state identifier, and performs a low-power wait with window deadline constraints during non-real-time window periods, including: Before each wait, the address monitoring setting is performed on the cache line where the window status identifier is located, and the window status identifier is read again. After confirming that the current window is still in a non-real-time window state, low-power wait is started. Use the processor time count corresponding to the current window deadline timestamp as the timeout constraint value for low-power waiting, and set the processor state for low-power waiting to a shallow sleep waiting state. After exiting the low-power wait due to a shared memory page write or timeout, read the monotonically increasing sequence number and window status identifier to determine whether a window switch has occurred and the wake-up source. After confirming entry into the real-time window, read the real-time window start timestamp to execute the corresponding real-time workload.

[0069] Specifically, this application's user-mode real-time thread sets hardware address monitoring for the cache line containing the window state identifier and performs low-power waiting with window deadline constraints during non-real-time window periods. This is a direct cooperation between the aforementioned shared memory page mapping mechanism and the raw interrupt handling entry writing mechanism on the user-mode side. This implementation does not use traditional busy polling, blocking system calls, or signal waiting methods to detect window switching. Instead, it utilizes the hardware address monitoring capability provided by the processor to establish a monitoring relationship with the cache line containing the window state identifier in the shared memory page. This causes the user-mode real-time thread to enter a shallow sleep waiting state during non-real-time window periods and is directly woken up by the processor's cache coherence mechanism when the corresponding cache line of the shared memory page is written to by the kernel side. This limits the window switching detection process to between direct user-mode reading and hardware waiting exit.

[0070] In this embodiment, after startup, the user-mode real-time thread preferably first completes registration with the loadable kernel extension and mapping to shared memory pages, so as to directly access the window state identifier, monotonically increasing sequence number, real-time window start timestamp, real-time window end timestamp, and non-real-time window end timestamp within its own address space. Specifically, on an Intel x86-64 processor platform and in a Linux 5.15 kernel environment, the user-mode real-time thread can be configured with a real-time first-in-first-out scheduling strategy and bound to the target processor for execution. Thus, after the aforementioned raw interrupt handling entry point updates the window state data in the shared memory page on the target processor, the user-mode real-time thread can directly perform window state confirmation and real-time load scheduling based on this shared memory page without needing an additional scheduling wake-up link.

[0071] Before each wait, the user-mode real-time thread first performs address monitoring and setting on the cache line containing the window status identifier. Since the window status identifier, along with key fields such as the monotonically increasing sequence number and the real-time window start timestamp, are concentrated within a single cache line in the aforementioned embodiments, monitoring the cache line containing the window status identifier covers the most critical data write area during window switching. Subsequently, the user-mode real-time thread reads the window status identifier again to confirm that it is still in a non-real-time window state. The reason for reading the window status identifier again after performing address monitoring and setting is to eliminate the race condition between address monitoring and setting and the initiation of low-power wait. In other words, if the raw interrupt handling entry point has updated the shared memory page to the real-time window state precisely after address monitoring and setting and before low-power wait initiation, this second read operation can promptly detect that a window switch has occurred, thereby preventing the user-mode real-time thread from incorrectly entering subsequent wait processes.

[0072] After confirming that the current state is still in a non-real-time window state, the user-space real-time thread initiates a low-power wait. This low-power wait is not an unrestrained, continuous blocking, but rather subject to a window deadline constraint. Specifically, the user-space real-time thread reads the current window deadline timestamp from the shared memory page and uses the processor time count corresponding to this deadline timestamp as the timeout constraint value for the low-power wait. With this setting, if the raw interrupt handling entry triggers a cache line state change by writing to the shared memory page before the current non-real-time window ends, the user-space real-time thread will exit the wait early due to the shared memory page write; if the kernel fails to write the window state data at the expected time, or if hardware address monitoring is not triggered for other reasons, the low-power wait will exit due to timeout when the window deadline is reached. Furthermore, in this embodiment, it is preferable to set the processor state corresponding to the low-power wait to a shallow sleep wait state, so as to maintain low waiting power consumption while ensuring a fast wake-up response speed.

[0073] After exiting the low-power wait, the user-space real-time thread does not immediately assume it has entered the real-time window. Instead, it first reads the monotonically increasing sequence number and the window status flag to determine whether a window switch has occurred and the source of the wake-up. If, after exiting the wait, the monotonically increasing sequence number has changed and the window status flag indicates that it is currently in the real-time window, then this exit is a window switch wake-up caused by a shared memory page write. If the window status flag still indicates a non-real-time window, or the monotonically increasing sequence number has not changed but the current processor time count has reached the window cutoff time, then this exit can be determined to be a timeout wake-up. In a specific example, after determining that it has entered the real-time window, the user-space real-time thread can further read the real-time window start timestamp and associate the current processor time count with the real-time window start timestamp to determine the perceived latency between writing to the shared memory page from the raw interrupt handling entry point and the resumption of execution of the user-space real-time thread, and simultaneously start the corresponding real-time workload accordingly.

[0074] For example, in a specific test case, the window period is set to 1000 microseconds, and the real-time window ratio is set to 80%. When the user-space real-time thread detects that it is currently in a non-real-time window, it first performs address monitoring settings on the cache line where the window status identifier is located, then reads the window status identifier again to confirm that it is still a non-real-time window, and then uses the processor time count corresponding to the non-real-time window's expiration timestamp as the timeout constraint value, entering a shallow sleep waiting state. When the raw interrupt handling entry updates the window status identifier to a real-time window and writes the real-time window start timestamp at the start of the next real-time window, the processor cache coherence mechanism detects that a write operation has occurred in the monitored cache line, and the user-space real-time thread immediately exits the low-power wait. After exiting, the thread reads the monotonically increasing sequence number and the window status identifier to confirm that the window has switched to a real-time window, then reads the real-time window start timestamp, and starts the real-time workload accordingly. If, in some scenarios, no shared memory page write is detected and the timeout constraint value is reached, the thread re-executes the window status confirmation and subsequent waiting process based on the timeout exit result.

[0075] Through the above implementation, this embodiment establishes a low-power waiting mechanism based on hardware address monitoring and window deadline constraints on the user-space side. This enables user-space real-time threads to wait for window switching in a shallow sleep mode during non-real-time window periods and quickly resume execution when shared memory pages are updated. This implementation reduces the additional processing overhead caused by busy polling and system call waiting, improves the timeliness of user-space real-time threads' perception of window switching and execution continuity, and provides reliable support for the rapid startup of real-time workloads at the beginning of the real-time window.

[0076] In some embodiments, after exiting the wait due to a shared memory page write, the window switching result is confirmed by combining the sequence number and window state identifier, and the corresponding real-time workload is executed according to the real-time window start timestamp, including: After exiting the low-power wait, the monotonically increasing sequence number, window status identifier, real-time window start timestamp, and current window end timestamp are read sequentially according to the preset reading order, and the monotonically increasing sequence number is checked twice for consistency. When the consistency check passes, the system determines whether the real-time window has been entered based on the window status identifier. If the real-time window has been entered, the system associates the current processor time count with the real-time window start timestamp to determine the starting execution baseline and remaining window range of the real-time workload before starting the real-time workload. If the consistency check fails, the window status identifier indicates that the window has not entered the real-time window, or the current window's expiration timestamp indicates that the current window has expired, the address monitoring settings and low-power wait for the cache line containing the window status identifier will be re-executed.

[0077] Specifically, after exiting the wait due to a shared memory page write, this application confirms the window switching result by combining the sequence number and window state identifier, and executes the corresponding real-time workload based on the real-time window start timestamp. This is the subsequent confirmation and execution step of the aforementioned user-mode real-time thread low-power wait mechanism. The purpose of this step is not to directly assume that the window switching has been reliably completed after exiting the wait, but to determine whether the wake-up corresponds to a valid real-time window switching event by performing ordered reading and consistency verification of multiple key fields in the shared memory page. After confirming entry into the real-time window, the execution benchmark of the real-time workload and the remaining available window range are determined based on the real-time window start timestamp. This allows the user-mode real-time thread to maintain the accuracy of window state determination and the ability to control the workload start timing when resuming execution near the window boundary.

[0078] In this embodiment, after the user-mode real-time thread exits the low-power wait state, it preferably accesses the window state data in the shared memory page according to a preset reading order. The preset reading order is set because the window state identifier, monotonically increasing sequence number, real-time window start timestamp, and current window end timestamp in the shared memory page may all be written consecutively during window switching at the raw interrupt handling entry point. If the reading order is unconstrained, the user-mode real-time thread may read inconsistent data combinations. Therefore, this embodiment uses the monotonically increasing sequence number as the consistency verification benchmark field and preferably employs a method of "reading the sequence number first, then reading the window state identifier and timestamp field, and finally reading the sequence number again" to perform two consistency checks. With this setting, if the monotonically increasing sequence numbers read twice are consistent, it means that the shared memory page did not undergo another window state update during this read, and the currently read window state identifier, real-time window start timestamp, and current window end timestamp belong to the same window switching result; if the monotonically increasing sequence numbers read twice are inconsistent, it means that during the period when the user-mode real-time thread reads the above fields, the raw interrupt handling entry point performed a new write to the shared memory page, and the read result is no longer consistent, so the real-time workload should not be started based on the read result.

[0079] With a specific example, on an Intel x86-64 processor platform and in a Linux 5.15 kernel environment, after the UMWAIT instruction exits due to a shared memory page write, the user-mode real-time thread can first read the monotonically increasing sequence number in the shared memory page, then read the window state identifier, the real-time window start timestamp, and the current window end timestamp, and then read the monotonically increasing sequence number again and compare them. If the comparison results are consistent, the subsequent window state determination process continues; if the comparison results are inconsistent, it indicates that the shared memory page has been updated by the raw interrupt handling entry point between the two reads, for example, after switching from a non-real-time window to a real-time window and then a rapid next state change. In this case, the user-mode real-time thread no longer starts the real-time workload based on the current data, but instead re-executes the address monitoring settings and low-power wait for the cache line where the window state identifier is located.

[0080] Upon successful consistency verification, the user-mode real-time thread determines whether it has entered a real-time window based on the window status identifier. If the window status identifier indicates that it is currently in a real-time window, the current processor time count is further associated with the real-time window start timestamp. The real-time window start timestamp is synchronously written by the aforementioned raw interrupt handling entry point when writing the real-time window identifier, and is used to identify the processor time count at which the kernel side recognizes the start of the real-time window. After reading this field, the user-mode real-time thread can subtract the real-time window start timestamp from the current processor time count to determine the time consumed between window switching and user-mode resumption of execution, and simultaneously combine this with the current window end timestamp to determine the remaining available range of the current real-time window. For example, in the 1000-microsecond cycle and 80% real-time window ratio scenario of the aforementioned embodiment, if the user-mode real-time thread, after being awakened, reads that the current processor time count is only slightly greater than the real-time window start timestamp, it indicates that the remaining real-time window range is large, and a full real-time workload can be started directly; if the current processor time count is close to the current window end timestamp, the scale of this real-time workload can be reduced based on the remaining window range, or only critical processing that must be completed within this real-time window can be executed.

[0081] If the consistency check fails, or the window status indicator indicates that the real-time window has not yet been entered, or the current window's expiration timestamp indicates that the current window has expired, the user-space real-time thread will not execute the real-time workload but will return to the waiting phase to re-establish the monitoring relationship. The term "current window expired" means that when the user-space real-time thread completes field reading and judgment, the current processor time count has reached or exceeded the current window's expiration timestamp. Even if the window status indicator still indicates a real-time window, this means that the effective execution interval corresponding to this window switch has ended, and it is not advisable to continue starting the real-time workload based on the expired window. Referring to the specific examples in the aforementioned embodiments, when the user-space real-time thread determines that any of the above conditions are met, it can reset the monitoring settings for the cache line execution address where the window status indicator is located, read the window status indicator again to confirm the current state, and enter the next round of low-power waiting to await the arrival of a subsequent effective window switch event.

[0082] For example, in a specific test case, after the user-space real-time thread exits UMWAIT due to a shared memory page write, it sequentially reads the monotonically increasing sequence number, the window state identifier, the real-time window start timestamp, and the current window end timestamp, and then reads the monotonically increasing sequence number again. If the two sequence numbers match, and the window state identifier is a real-time window, the current timestamp counter value is subtracted from the real-time window start timestamp to obtain the current perceived delay. Then, the current window end timestamp is subtracted from the current timestamp counter value to obtain the remaining window interval, and the corresponding real-time computing task is started based on this remaining window interval. If the two sequence numbers do not match, it indicates that the shared memory page was updated again during the read, and the thread immediately abandons the current judgment result and re-enters the monitoring and waiting process.

[0083] Through the above implementation method, this embodiment establishes a consistency verification mechanism based on a monotonically increasing sequence number after the user-mode real-time thread exits the low-power wait state. It also combines the window state identifier, the real-time window start timestamp, and the current window end timestamp to complete the confirmation of window switching results and the control of real-time workload startup. This implementation method can reduce the risk of misjudgment of state caused by concurrent reading of multiple fields, improve the accuracy of the user-mode real-time thread in identifying valid real-time windows, and enhance the timing matching capability between the real-time workload and the remaining window interval.

[0084] The technical solutions of the embodiments of this application described above will be further explained below with reference to specific examples.

[0085] Example 1: Basic Implementation This embodiment implements a loadable kernel module (module name: rms_tp_tsc_kernel.ko) and a corresponding user-space test program on the Intel x86-64 processor platform, based on the Linux 5.15 kernel operating system.

[0086] 1. Data structure design for shared memory pages Shared memory pages are defined using the following data structure, aligned to 64-byte cache line boundaries to avoid false sharing: struct isr_direct_shm { u32 window_state; / / Offset 0: Window state (0=NRT, 1=RT) u32 sequence; / / Offset 4: Monotonically increasing sequence number u64 rt_deadline_tsc; / / Offset 8: RT window cutoff TSC u64 nrt_deadline_tsc; / / Offset 16: NRT window cutoff TSC u64 stats_rt_switches; / / Offset 24: RT handover statistics u64 stats_nrt_switches; / / Offset 32: NRT handover statistics u64 stats_max_rt_ns; / / Offset 40: Maximum RT latency statistics u64 rt_start_tsc; / / Offset 48: RT window start TSC u64 padding[2]; / / Offset 56: pad to cache line alignment } __aligned(64); Among them, `window_state` and `rt_start_tsc` are the two fields most important to the user-space real-time thread. `window_state` is atomically written by the raw interrupt service routine, and the user thread reads it through atomic loading semantics. `rt_start_tsc` records the TSC value when the raw interrupt service routine writes the real-time window state. After reading it, the user thread can calculate the delay from the interrupt occurrence to the perceived window switching.

[0087] 2. Allocation of shared memory pages in kernel modules Kernel modules allocate shared memory pages when user-mode processes register: (1) Allocate a physical page using alloc_page(GFP_KERNEL | __GFP_ZERO); (2) Use page_address() to obtain the kernel virtual address and store it in the per-CPU context structure; (3) Set page reference count to ensure proper lifecycle management during mmap and module unloading.

[0088] 3. mmap mapping for user-space processes User-mode processes map shared memory pages through the following calls: mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, ISR_DIRECT_SHM_PGOFF *PAGE_SIZE) The `ISR_DIRECT_SHM_PGOFF` parameter is defined as 0xFFFFF and serves as the page offset magic number to distinguish this mapping request from a regular mmap request for the device file. The kernel module's mmap handler checks if `vma->vm_pgoff` equals this magic number. If they match, it sets the `VM_DONTEXPAND | VM_DONTDUMP` flag and uses `vm_insert_page()` to insert the shared memory physical page into the user process's page table, with read-only mapping permissions.

[0089] 4. Compiler attributes of raw interrupt service routines Raw interrupt service routine declarations use two key compiler properties: (1) __attribute__((naked)): tells the compiler not to generate function prologue (i.e., pushhrbp; mov rbp, rsp, etc.) and epilogue (i.e., pop rbp; ret, etc.), and the function body is completely controlled by the programmer through inline assembly; (2) __attribute__((no_instrument_function)): Instructs the compiler not to insert __fentry__ tracing calls at function entry points. In the Linux kernel, when ftrace / kprobe is enabled, the compiler inserts a call __fentry__ instruction (occupying 5 bytes) at each function entry point. For raw functions, this insertion causes a stack layout offset: the raw function expects 8(%rsp) to be the CS register in the interrupt return frame used to determine the privilege level of the interrupt source (testl $3, 8(%rsp)), but the call instruction of __fentry__ pushes an extra return address, making the actual offset 16(%rsp), causing an error in the swapgs judgment logic.

[0090] 5. Saving and restoring the GPR of a raw interrupt service routine The bare interrupt service routine saves and restores all 15 x86-64 general-purpose registers in a fixed order using inline assembly. The saving order (from low to high address) is: r15, r14, r13, r12, rbp, rbx, r11, r10, r9, r8, rdi, rsi, rdx, rcx, rax, totaling 15 x 8 = 120 bytes. During restoration, the registers are popped in reverse order. This order corresponds one-to-one with the register frame structure isr_saved_regs defined in the C language handler function, allowing the handler function to access the register values ​​of the interrupted context through the structure pointer.

[0091] 6. LAPIC TSC-Deadline Mode Configuration During kernel module initialization, the target processor's LAPIC is configured to TSC-Deadline mode: (1) Read the timer register (LVTT, offset 0x320) of the LAPIC local vector table and set the mode bit to TSC-Deadline mode (bit 18 = 1, bit 17 = 0). (2) Set the interrupt vector to 0xF5 (priority class 15, this vector number is marked as unused in the Linux kernel's irq_vectors.h); (3) Write MSR IA32_TSC_DEADLINE (address 0x6E0) to set the first interrupt trigger time.

[0092] 7. Specific implementation of two-level kprobe indirect symbolic resolution The specific steps for the first-level parsing are as follows: (1) Initialize a kprobe structure and set the symbol_name field to the string "kallsyms_lookup_name"; (2) The probe point is registered by calling register_kprobe(). Since the kallsyms_lookup_name function is not in the .noinstr.text code segment, the blacklist check of the kprobe subsystem passes and the registration is successful; (3) Read the kp.addr field from the successfully registered kprobe structure. This field is the kernel virtual address of the kallsyms_lookup_name function; (4) Immediately call unregister_kprobe() to unregister the probe point to avoid continuous impact on system performance; (5) Convert the obtained address to a function pointer type unsigned long (*)(const char *) and cache it in a static variable.

[0093] The second-level parsing utilizes the function pointers obtained in the first level: (1) Calling lookup_fn("rcu_irq_enter") will cause kallsyms_lookup_name to look up the address corresponding to the symbol name in the kernel symbol table. Although rcu_irq_enter is located in the .noinstr.text segment and is listed in the kprobe blacklist, the lookup mechanism of kallsyms_lookup_name is not restricted by the kprobe blacklist and can return the address normally; (2) Similarly, call lookup_fn("rcu_irq_exit") to get the address of rcu_irq_exit; (3) Store the two addresses as function pointers of type void (*)(void) and use them indirectly in the C handler function of the bare interrupt service routine. If the resolution fails (the function pointer is null), the call is skipped and the bare interrupt service routine can still run normally, but it may trigger an RCU pause warning when running for a long time on a non-isolated processor.

[0094] 8. Specific implementation of user-mode UMWAIT wait The wait loop implementation for the user-mode real-time thread is as follows: (1) At the start of each loop iteration, the UMONITOR instruction (machine code F3 48 0F AE F0) is used to set the address of the shared memory page window_state field stored in the rax register to the monitoring address. The UMONITOR instruction informs the processor to start monitoring the memory operations of the cache line (64-byte aligned) where this address is located; (2) Before executing UMWAIT, atomically load window_state again to confirm that it is still in a non-real-time window state to avoid race conditions caused by window switching between UMONITOR and UMWAIT; (3) Use the UMWAIT instruction (machine code F2 48 0F AE F1) to enter the low power standby state. The parameters are set as follows: ecx = 1 (C0.1 state, shallow sleep, faster wake-up), edx:eax = non-real-time window cutoff TSC value (timeout protection). (4) UMWAIT exits in two ways: a storage operation occurs on the monitored cache line (CF=0, indicating that it was woken up by the interrupt service routine writing to shared memory) or TSC reaches the timeout value (CF=1, indicating that it was woken up by timeout). The two situations are distinguished by checking the CF flag. (5) After being woken up, directly read the window_state field in the shared memory page to confirm the window state. If it is a real-time window, read the rt_start_tsc field and calculate the perceived latency with the difference between the current TSC, and then execute the real-time workload.

[0095] 9. Self-IPI Keep-Alive Mechanism on Non-Isolated Processors When the target processor is not isolated by the isolcpus parameter, the C handler function of the raw interrupt service routine maintains a decrementing counter linux_kick_counter, initially set to 10. This counter is decremented with each interrupt handling, and when the counter reaches zero: (1) Send an IPI to itself through LAPIC ICR (Interrupt Command Register), with the target vector being the original timer interrupt vector of the Linux kernel (saved from LVTT at startup); (2) The self-IPI is received and delivered by the processor after the bare interrupt service routine returns, triggering the execution of the Linux kernel's raw timer interrupt handler; (3) The Linux raw timer interrupt handler is executed through the normal irq_enter() / irq_exit() path, updating the scheduler clock tick, handling timer soft interrupts, and advancing the RCU state machine; (4) The counter is reset to 10, and the next keep-alive cycle begins.

[0096] With a default ISR cycle of 100 microseconds, the self-IPI transmission frequency is once every 1 millisecond (100μs x 10 = 1ms), which meets the clock tick requirement under the Linux kernel configuration of CONFIG_HZ=1000.

[0097] Example 2: Performance Test Data Performance tests were conducted using an Intel Atom x6425RE processor (4 cores, shared L2 1.5MB / L3 4MB) under the following configuration: Test Configuration A: Isolated Processor + L2 Cache Partition Kernel parameters: isolicpus=2, nohz_full=2, rcu_nocbs=2, nopti, nmi_watchdog=0 L2 CAT configuration: RT partition 3-way exclusive, Linux 9-way ISR period: 1000 microseconds (1 millisecond) RT window ratio: 80% Test duration: 3600 seconds Sample size: 3,599,175 Test results: Average jitter: 3.12 microseconds P99.9 Jitter: 3.48 microseconds Maximum jitter: 12.32 microseconds Anomaly rate greater than 5 microseconds: 2.5 / million Average wake-up latency from ISR to user space: 0.34 microseconds (340 nanoseconds) Test Configuration B: Non-isolated processor + dual-IDT interrupt isolation No isolcpus parameter Enable dual-IDT IPI delay (0xFB + 0xFD vector) ISR period: 1000 microseconds Test duration: 60 seconds Sample size: 55,958 Test results: P99.9 Jitter: 3.59 microseconds Maximum jitter: 4.69 microseconds Anomaly rate greater than 5 microseconds: 0 / million Average wake-up latency from ISR to user space: 0.47 microseconds (470 nanoseconds) The test results above verify that the method of this application can achieve sub-microsecond window switching perceived latency and microsecond-level real-time jitter performance in both isolated and non-isolated processor configurations.

[0098] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0099] Figure 2 This is a schematic diagram of the structure of a real-time window switching device based on shared memory and hardware monitoring instructions provided in an embodiment of this application. Figure 2 As shown, the device includes: The allocation module 201 is used to allocate shared memory pages for the target processor in the general operating system kernel through loadable kernel extensions, establish window state data aligned to processor cache lines in the shared memory pages, and map the shared memory pages to the address space of the user-mode real-time process in a read-only shared mapping manner. The window state data includes window state identifier, monotonically increasing sequence number, real-time window start timestamp, and current window end timestamp. The setting module 202 is used to configure the local timer of the target processor to the deadline trigger mode, and set the entry of the corresponding interrupt vector to the raw interrupt handling entry for bypassing the kernel standard interrupt to enter and exit the framework. When the timer interrupt is triggered, the processor time count is read, it is determined whether the current window should be entered or not, and the window state data is updated, the task priority masking threshold is set, and the deadline corresponding to the next window switching time is loaded according to the determination result. Trigger module 203 is used to independently maintain dynamic tick accounting for each processor during the execution of the raw interrupt handling entry point, and trigger the original timed interrupt path according to the preset interrupt cycle; The execution module 204 is used for monitoring the hardware address of the cache line where the window status identifier is located in the user-mode real-time thread, performing low-power wait with window deadline constraints during non-real-time window periods, and exiting the wait due to shared memory page writes. After exiting the wait, it confirms the window switching result by combining the sequence number and the window status identifier, and executes the corresponding real-time workload according to the real-time window start timestamp.

[0100] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0101] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0102] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0103] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0104] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0107] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A real-time window switching method based on shared memory and hardware monitoring instructions, characterized in that, include: A shared memory page is allocated for the target processor in the general operating system kernel through a loadable kernel extension. Window state data aligned to processor cache lines is established in the shared memory page, and the shared memory page is mapped to the address space of the user-mode real-time process in a read-only shared mapping manner. The window state data includes a window state identifier, a monotonically increasing sequence number, a real-time window start timestamp, and a current window end timestamp. Configure the target processor's local timer to deadline trigger mode, and set the entry of the corresponding interrupt vector to the raw interrupt handling entry for bypassing the kernel standard interrupt to enter and exit the framework. When the timer interrupt is triggered, read the processor time count, determine whether to enter the real-time window or the non-real-time window, and update the window state data, set the task priority masking threshold, and load the deadline corresponding to the next window switching time according to the determination result. During the execution of the raw interrupt handling entry point, dynamic tick accounting for each processor is maintained independently, and the original timed interrupt path is triggered according to the preset interrupt cycle; The user-mode real-time thread sets hardware address monitoring for the cache line containing the window state identifier. During non-real-time window periods, it performs low-power wait with window deadline constraints. After exiting the wait due to the shared memory page write, it confirms the window switching result by combining the sequence number and the window state identifier, and executes the corresponding real-time workload according to the real-time window start timestamp.

2. The method according to claim 1, characterized in that, The method of allocating shared memory pages for the target processor in a general-purpose operating system kernel through loadable kernel extensions includes: When a user-mode real-time process is registered, a physical page is allocated to the target processor and a kernel address mapping of the physical page is established, thus associating the user-mode real-time process with the target processor. Initialization processing is performed on the physical page, and the window state data is constructed in the physical page according to the processor cache line alignment rule; In response to the memory mapping request initiated by the user-mode real-time process, the mapping request for the shared memory page is identified according to the preset mapping identifier, and the physical page is inserted into the virtual address region corresponding to the user-mode real-time process; The inserted physical page is set to a read-only shared mapping so that the user-mode real-time process can read the window state data based on the shared memory page.

3. The method according to claim 1, characterized in that, The step of establishing window state data aligned to processor cache lines in the shared memory page and mapping the shared memory page to the address space of the user-mode real-time process in a read-only shared mapping manner includes: Perform zeroing initialization on the shared memory page, and construct a window state data area in the shared memory page that is aligned with the boundary of a single processor cache line; In the window state data area, a window state identifier field, a monotonically increasing sequence number field, a real-time window start timestamp field, a real-time window end timestamp field, and a non-real-time window end timestamp field are set so that window state switching information and corresponding timing information are stored in the same cache line range. In response to the shared mapping request initiated by the user-mode real-time process, the mapping object for the shared memory page is identified according to the preset page offset identifier, and the shared memory page is inserted into the virtual address region corresponding to the user-mode real-time process; The virtual address region is set to a read-only shared mapping attribute so that the user-mode real-time process can directly read the window state identifier field, the monotonically increasing sequence number field, and the timestamp field without modifying the window state data.

4. The method according to claim 1, characterized in that, The step of configuring the target processor's local timer to a deadline-triggered mode and setting the corresponding interrupt vector entry point as a raw interrupt handling entry point that bypasses the kernel's standard interrupts to enter and exit the framework includes: Configure the local timer register of the target processor to perform mode configuration, set the local timer to a timer interrupt source triggered based on the processor time count cutoff value, and write the cutoff time corresponding to the first window switching time into the cutoff time register; A preset high-priority interrupt vector is assigned to the timer interrupt source, and the high-priority interrupt vector is higher than the maskable interrupt priority class corresponding to the task priority masking threshold during the real-time window. The raw interrupt handling entry point is constructed, which adopts raw function declaration and uninstrumented declaration, and implements interrupt source privilege level judgment, segment base address register switching, general-purpose register saving and processing context passing through inline assembly. The interrupt descriptor table entry corresponding to the high-priority interrupt vector is updated to point to the raw interrupt handling entry. After the window switching process is completed at the raw interrupt handling entry, the general-purpose register is restored, the segment base address register is restored, and the interrupt is returned via inline assembly.

5. The method according to claim 1, characterized in that, The step of reading the processor time counter when a timer interrupt is triggered, determining whether to enter a real-time window or a non-real-time window, and updating the window state data, setting the task priority masking threshold, and the deadline for loading the next window switching time based on the determination result includes: In the processing corresponding to the raw interrupt processing entry, the current processor time count is read, and the target window type is determined by combining the current window deadline timestamp and the preset window switching order; When the target window type is a real-time window, write the real-time window identifier, the real-time window start timestamp, and the real-time window end timestamp, increment the monotonically increasing sequence number, adjust the task priority masking threshold to a masking threshold that only allows the high-priority interrupt vector to penetrate, and load the end time corresponding to the end time of the real-time window. When the target window type is a non-real-time window, write the non-real-time window identifier and the non-real-time window deadline timestamp, increment the monotonically increasing sequence number, restore the task priority masking threshold, and load the deadline time corresponding to the start time of the next real-time window.

6. The method according to claim 1, characterized in that, During the execution of the raw interrupt handling entry point, the process independently maintains dynamic tick accounting for each processor and triggers the original timed interrupt path according to a preset interrupt cycle, including: In the processing corresponding to the raw interrupt handling entry point, the interrupt entry accounting function is called before the window switching process and the interrupt exit accounting function is called after the window switching process to perform independent updates to the dynamic tick count corresponding to the current processor. The interrupt entry accounting function and the interrupt exit accounting function are not triggered by the kernel standard interrupt entry and exit framework. The function addresses of the interrupt entry accounting function and the interrupt exit accounting function are obtained through a two-level indirect symbol resolution method. The two-level indirect symbol resolution method includes: obtaining the address of the kernel symbol lookup function based on the kernel probe point, and looking up the addresses of the interrupt entry accounting function and the interrupt exit accounting function based on the kernel symbol lookup function. An interrupt cycle counter is maintained in the processing corresponding to the raw interrupt processing entry. When the interrupt cycle counter reaches a preset number of cycles, an inter-processor interrupt is sent to the original timer interrupt vector, and the interrupt cycle counter is reset after the original timer interrupt path is triggered.

7. The method according to claim 1, characterized in that, The user-mode real-time thread sets hardware address monitoring for the cache line containing the window state identifier, and performs low-power waits with window deadline constraints during non-real-time window periods, including: Before each entry into the wait state, the address monitoring setting is performed on the cache line where the window state identifier is located, and the window state identifier is read again. After confirming that the current window state is still in a non-real-time window state, the low-power wait state is started. The processor time count corresponding to the current window deadline timestamp is used as the timeout constraint value for the low-power wait, and the processor state of the low-power wait is set to a shallow sleep wait state. After exiting the low-power wait due to a shared memory page write or timeout, the monotonically increasing sequence number and the window state identifier are read to determine whether a window switch has occurred and the wake-up source. After confirming entry into the real-time window, the real-time window start timestamp is read to execute the corresponding real-time workload.

8. The method according to claim 7, characterized in that, After exiting the wait due to the shared memory page write, the window switching result is confirmed by combining the sequence number and window state identifier, and the corresponding real-time workload is executed according to the real-time window start timestamp, including: After exiting the low-power wait, the monotonically increasing sequence number, the window status identifier, the real-time window start timestamp, and the current window end timestamp are read sequentially according to the preset reading order, and the monotonically increasing sequence number is checked for consistency twice. When the consistency check passes, it is determined whether the real-time window has been entered based on the window status identifier. If it is determined that the real-time window has been entered, the current processor time count is associated with the start timestamp of the real-time window. After determining the start execution baseline and remaining window interval of the real-time workload, the real-time workload is started. If the consistency check fails, the window status identifier indicates that the window has not entered the real-time window, or the current window expiration timestamp indicates that the current window has expired, the address monitoring settings and low-power wait for the cache line containing the window status identifier are re-executed.

9. A real-time window switching device based on shared memory and hardware monitoring instructions, characterized in that, include: The allocation module is used to allocate shared memory pages for the target processor in the general operating system kernel through loadable kernel extensions, establish window state data aligned to processor cache lines in the shared memory pages, and map the shared memory pages to the address space of the user-mode real-time process in a read-only shared mapping manner. The window state data includes a window state identifier, a monotonically increasing sequence number, a real-time window start timestamp, and a current window end timestamp. The configuration module is used to configure the target processor's local timer to the deadline trigger mode and set the entry of the corresponding interrupt vector to the raw interrupt handling entry for bypassing the kernel standard interrupt to enter and exit the framework. When the timer interrupt is triggered, the processor time count is read to determine whether the current window should be entered into a real-time window or a non-real-time window. Based on the determination result, the window state data is updated, the task priority masking threshold is set, and the deadline corresponding to the next window switching time is loaded. The triggering module is used to independently maintain the dynamic tick accounting for each processor during the execution of the raw interrupt handling entry point, and trigger the original timed interrupt path according to the preset interrupt cycle; The execution module is used for user-mode real-time threads to set hardware address monitoring for the cache line where the window state identifier is located, to perform low-power wait with window deadline constraints during non-real-time window periods, and to exit the wait due to the shared memory page write. After exiting the wait, it confirms the window switching result by combining the sequence number and the window state identifier, and executes the corresponding real-time workload according to the real-time window start timestamp.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 8.

Images