Runtime CPU fault-tolerant system based on heterogeneous computing

Abstract

The invention discloses a runtime CPU fault-tolerant system based on heterogeneous computing, and relates to the technical field of processor management. The host process execution module plans a calculation task of a host process of a target program and divides the calculation task into a plurality of execution segments capable of being checked in parallel according to a preset rule, and the check point management module creates check points and provides an execution starting point which is completely the same as the host process at a certain time for the heterogeneous check module; the method comprises the steps that a host process is started to be executed, a check process can reproduce the execution process of the host process from an execution starting point, check of the execution result of the host process is achieved, a heterogeneous check module executes check tasks in parallel through a small core of a heterogeneous processor and reproduces execution logic of the host process to detect errors, and a state comparison module compares the execution results of the host process and the check process. The state difference caused by hardware faults is recognized, the scheduling and energy efficiency optimization module dynamically manages resource allocation of the check process, core scheduling, frequency adjustment and load balancing are carried out, and the system interaction module processes interaction between a program and an operating system to ensure that external behaviors of the check process and the host process are consistent.

Description

TECHNICAL FIELD

[0001] The application discloses a runtime CPU fault-tolerant system based on heterogeneous computing and relates to the technical field of processor management. BACKGROUND

[0002] With the continuous progress of semiconductor technology, the silicon-based defect risk faced by processors is increasing day by day, which makes problems such as silent data corruption (SDC) frequently occur. Although the existing hardware lockstep system and software replication scheme can realize fault detection, they still have many deficiencies. For example, the hardware lockstep system will double the energy consumption, and the software replication scheme will halve the performance, and some schemes also depend on hardware modification, which brings great limitations in the deployment process. Although the heterogeneous parallel fault-tolerant technology such as ParaMedic reduces the overhead to a certain extent by means of small core parallel execution of the verification task, it still depends on hardware support and greatly limits the actual application. SUMMARY

[0003] The application provides a runtime CPU fault-tolerant system based on heterogeneous computing, which realizes efficient fault detection by means of heterogeneous parallel mechanism without relying on hardware modification, is suitable for heterogeneous processor architecture with large and small cores, and can significantly reduce the overhead of fault-tolerant scheme in terms of energy consumption and performance.

[0004] The specific scheme provided by the application is as follows:

[0005] The application provides a runtime CPU fault-tolerant system based on heterogeneous computing, which includes a main process execution module, a checkpoint management module, a heterogeneous checking module, a state comparison module, a scheduling and energy efficiency optimization module and a system interaction module,

[0006] The main process execution module plans the computing task of the main process of the target program, and divides the computing task into multiple executable segments that can be checked in parallel according to a preset rule,

[0007] The checkpoint management module creates a checkpoint, provides the heterogeneous checking module with an execution starting point that is completely the same as the main process at a certain time, enables the checking process to reproduce the execution process of the main process from the execution starting point, and realizes the checking of the execution result of the main process,

[0008] The heterogeneous checking module executes the checking task by means of the small core of the heterogeneous processor, reproduces the execution logic of the main process to detect errors,

[0009] The state comparison module compares the execution results of the main process and the checking process, identifies the state difference caused by hardware failure,

[0010] The scheduling and energy efficiency optimization module dynamically manages the resource allocation of the checking process, performs core scheduling, adjusts the frequency and balances the load,

[0011] The system interaction module handles the interaction with the operating system, ensuring that the inspection process is consistent with the external behavior of the main process.

[0012] Further, the checkpoint management module of the runtime CPU fault-tolerant system based on heterogeneous computing creates checkpoints, including:

[0013] When the main process executes to the preset execution segment boundary, a copy of the main process is created using the write-once-copy approach through the relevant interface of the operating system, and the copy is the checkpoint process,

[0014] and the current register state of the main process is saved, including the general register, program counter PC, and stack pointer SP.

[0015] Further, the heterogeneous inspection module of the runtime CPU fault-tolerant system based on heterogeneous computing uses hardware performance counters and breakpoint mechanisms to ensure that the inspection process reaches the same execution point as the main process, including:

[0016] During the execution of the main process, when each checkpoint is reached, the number of branches executed in the user mode within the current segment is recorded using the hardware performance counter, and the value of the current program counter PC is read to identify the execution point of the main process at the end of the current segment.

[0017] Further, the state comparison module of the runtime CPU fault-tolerant system based on heterogeneous computing compares the execution results of the main process and the inspection process to identify state differences caused by hardware faults, including: locating the modified memory pages within the execution segment through the soft dirty page mechanism or page mapping count; calculating the hash value of the dirty page data and comparing it with the hash value of the corresponding page of the main process, while checking the register state, and triggering the error handling process when inconsistencies are found, terminating the program or recording fault logs.

[0018] Further, when the state comparison module of the runtime CPU fault-tolerant system based on heterogeneous computing identifies the modified memory pages within the execution segment, it tracks those modified memory pages during the execution of the main process and the inspection process, and the modified memory pages are referred to as dirty pages; different tracking methods are used for different architectures, in the x86_64 architecture, the Soft-Dirty soft dirty page mechanism of the Linux kernel is used to identify modified pages through page table markers; in the AArch64 architecture, the PAGEMAP_SCAN interface is customized to count the page mapping count to locate private modified pages.

[0019] Further, when the small core is insufficient, the scheduling and energy efficiency optimization module in the runtime CPU fault tolerance system based on heterogeneous computing will check the task migration of the process to the large core, and avoid the blocking of the main process; the small core frequency is adjusted through the dynamic voltage frequency scaling (DVFS) mode, to ensure the synchronization of the checking process and the main process; and the load of each core is monitored to avoid resource waste or overload.

[0020] Further, when the system interaction module of the runtime CPU fault tolerance system based on heterogeneous computing processes the interaction with the operating system, the system call operation is intercepted and classified, different processing strategies are adopted for different types of call operations, and the signal transmission is managed to ensure that the external signal is at the same execution point of the main process and the checking process.

[0021] The application also provides a runtime CPU fault tolerance method based on heterogeneous computing, which uses the runtime CPU fault tolerance system based on heterogeneous computing for CPU fault tolerance in the runtime of heterogeneous computing.

[0022] The application has the following advantages:

[0023] By dynamically dividing the program execution into multiple segments, using the small core to perform the verification task in parallel, combining the write-time copy checkpoint, the execution point replay, and the fast dirty page hash comparison technology, efficient fault detection is achieved. Compared with the existing scheme, the application does not need to modify the hardware, is suitable for mobile devices, data centers and other scenes with extremely high requirements for energy efficiency and reliability, and provides a low-overhead and high-reliability fault tolerance solution for the heterogeneous computing environment. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 is an execution segment schematic diagram.

[0025] Figure 2 is a system architecture schematic diagram of the application.

[0026] Figure 3 is a system module execution flow schematic diagram of the application. DETAILED DESCRIPTION

[0027] The application will be further described below in combination with the drawings and specific embodiments, so that those skilled in the art can better understand the application and implement it, but the embodiments are not limiting to the application.

[0028] Embodiment 1

[0029] The application provides a runtime CPU fault tolerance system based on heterogeneous computing, which comprises a main process execution module, a checkpoint management module, a heterogeneous checking module, a state comparison module, a scheduling and energy efficiency optimization module, and a system interaction module,

[0030] The main process execution module plans the computing task of the main process of the target program, and divides the computing task into a plurality of parallel checkable execution segments according to preset rules such as an instruction cycle or a branch counting rule.

[0031] The checkpoint management module creates a checkpoint, provides a same execution starting point as the main process at a certain time for the heterogeneous check module, enables the check process to reproduce the execution process of the main process starting from the execution starting point, and realizes the check of the execution result of the main process.

[0032] The checkpoint management module creates a checkpoint, and includes:

[0033] When the main process executes to a preset execution segment boundary, a copy of the main process is created by using a write-on-copy mode through a related interface of an operating system, the copy is a checkpoint process,

[0034] and the current register state of the main process is saved, including a general register, a program counter PC and a stack pointer SP.

[0035] The heterogeneous check module executes the check task in parallel by using a small core of a heterogeneous processor, reproduces the execution logic of the main process, and detects errors.

[0036] The heterogeneous check module can specifically include:

[0037] During the execution of the main process, when each checkpoint is reached, the number of branches executed in a user mode in a current segment is recorded by using a hardware performance counter, and the value of a current program counter PC is read, which is used to identify the execution point of the main process at the end of the current segment, for example, there are 10,000 branch instruction numbers in the segment, and the ending address is 0x1100_0000.

[0038] The state comparison module compares the execution results of the main process and the check process, and identifies the state difference caused by a hardware fault.

[0039] The state comparison module compares the execution results of the main process and the check process, identifies the state difference caused by the hardware failure, and includes: locating the modified memory page in the execution segment through the soft dirty page mechanism or the page mapping count; calculating the hash value of the dirty page data, comparing the hash value of the corresponding page of the main process, checking the register state at the same time, triggering the error processing procedure when the inconsistency is found, terminating the program or recording the fault log. When the state comparison module identifies the modified memory page in the execution segment, the modified memory page is tracked during the execution of the main process and the check process, and the modified memory page is referred to as a dirty page; different tracking methods are used for different architectures, in the x86_64 architecture, the modified page is identified by using the soft dirty page mechanism Soft-Dirty of the Linux kernel through the page table mark; in the AArch64 architecture, the private modified page is located by using the self-defined PAGEMAP_SCAN interface to count the page mapping count.

[0040] The scheduling and energy optimization module dynamically manages the resource allocation of the check process, performs core scheduling, adjusts the frequency, and balances the load. When the small core is insufficient, the scheduling and energy optimization module migrates the task of the check process to the large core, and avoids blocking the main process; the frequency of the small core is adjusted by using the dynamic voltage frequency scaling DVFS mode, so that the check process and the main process are synchronized; and the load of each core is monitored to avoid resource waste or overload.

[0041] The system interaction module processes the interaction between the program and the operating system, and ensures that the external behaviors of the check process and the main process are consistent. When the system interaction module processes the interaction with the operating system, the system call operations such as global IO operations, process local memory mapping and the like are intercepted and classified, different processing strategies such as recording / replaying / emulation are used for different types of call operations; and the signal transmission such as the SIGINT signal is managed, so that the external signal is at the same execution point in the main process and the check process.

[0042] Embodiment 2

[0043] The application also provides a runtime CPU fault tolerance method based on heterogeneous computing, which uses the runtime CPU fault tolerance system based on heterogeneous computing to perform CPU fault tolerance in the runtime of heterogeneous computing.

[0044] The information interaction and execution process in the above method are based on the same concept as the method embodiments of the application, and the specific content can be referred to the description in the method embodiments of the application. The specific execution process can be referred to as follows:

[0045] The heterogeneous processor core topology is obtained by the scheduling and energy optimization module, such as 1 large core + 4 small cores, the core list is initialized, the main process is bound to the large core by default, and the check process is pre-allocated to the small core.

[0046] The system interaction module intercepts operating system signals, registers a custom signal handler, and ensures that the signal handling logic of the main process and the checking process are consistent. For external signals, the execution point when the main process receives the signal is recorded to ensure that the checking process handles the signal at the same execution point.

[0047] Starting the main process: The main process execution module loads the target program binary, creates a tracing process through the interface of the system interaction module, and starts runtime monitoring. The scheduling and energy efficiency optimization module starts the core load monitoring thread to collect real-time utilization and frequency of small cores, providing data basis for dynamic scheduling.

[0048] Segment division and checkpoint creation:

[0049] (1) Dynamic segment triggering: The system defaults to a segment period of 50 billion cycles. When the main process executes in user space for 50 billion cycles, dynamic segmentation is triggered. The main process execution module uses hardware performance counters to determine whether to enter the segment boundary. When the cycle count or branch count recorded by the hardware performance counter reaches the preset threshold, the main process execution module confirms that the segment boundary has been reached, and then initiates the subsequent checkpoint creation and checking process-related operations.

[0050] As shown in Figure 1 , after reaching the checkpoint, the heterogeneous checking module checks a segment of the main program and records the initial position of the next segment through the PC pointer.

[0051] Parallel execution of the heterogeneous checking module:

[0052] (1) Checking process startup: The scheduling and energy efficiency optimization module selects an idle core from the available small core list, migrates the checkpoint process to the target small core, and sets the core frequency to the initial value. The heterogeneous checking module configures the hardware performance counter for the checking process to monitor the branch count, and sets a breakpoint at the target PC.

[0053] Execution point reproduction: The checking process obtains checkpoint data, including memory state and execution point identifier, from the checkpoint management module. The checking process resumes execution from the checkpoint, and the small core starts executing the target segment code. When the branch count reaches the threshold, the performance counter overflows to trigger an interrupt, and the checking process enters a suspended state.

[0054] State comparison and error detection: The state comparison module compares the execution results of the main process and the checking process to identify state differences caused by hardware faults.

[0055] The flow of state comparison is: injecting xxHash calculation code to the main process and the check process through the state comparison module to calculate the hash value of the memory data of the dirty page. If consistent, skip, if inconsistent, mark as "memory difference", trigger error handling. Directly compare the register values of the main process and the check process, if the key register values such as general register, PC, SP are inconsistent, directly determine as "register difference".

[0056] Dynamic scheduling and energy efficiency optimization:

[0057] (1) Load monitoring and frequency adjustment: through the scheduling and energy efficiency optimization module, the utilization rate of the small core is monitored in real time, if the average utilization rate > 80%, the core frequency is increased or part of the check task is migrated to the large core; if the utilization rate < 20%, the frequency is reduced to save energy.

[0058] (2) Core migration strategy: when the small core queue is full, the earliest started check task is migrated to the large core through the scheduling and energy efficiency optimization module, the small core resource is released to process new segmentation. When the large core executes the check task, the idle period is used preferentially to avoid affecting the performance of the main process.

[0059] Program end and resource recycling: after the main process is executed, all unfinished check tasks are migrated to the large core through the scheduling and energy efficiency optimization module, the state comparison module forcibly compares the last execution segment, all checkpoint processes are destroyed through the checkpoint management module, and the write-time copy memory page is recycled; cancel ptrace tracking through the system interaction module, release hardware resources such as performance counter; reset the core frequency to the default value through the scheduling and energy efficiency optimization module, and clear the configuration.

[0060] Similarly, the advantages of the method of the application: by dynamically dividing the program execution into multiple segments, using small core to execute verification tasks in parallel, combining write-time copy checkpoint, execution point replay and fast dirty page hash comparison technology, efficient fault detection is realized. Compared with the existing scheme, the application does not need to modify the hardware, and is suitable for mobile devices, data centers and other scenes with high requirements for energy efficiency and reliability, and provides a low-overhead and high-reliability fault-tolerant solution for heterogeneous computing environment.

[0061] It should be noted that not all steps and modules in the above processes and system structures are necessary, and some steps or modules can be ignored according to actual needs. The execution order of each step is not fixed and can be adjusted as needed. The system structure described in the above embodiments can be a physical structure or a logical structure, that is, some modules can be implemented by the same physical entity, or some modules can be implemented by multiple physical entities, or can be implemented by some components in multiple independent devices.

[0062] The above-described embodiments are merely preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Any equivalent substitutions or transformations made by those skilled in the art based on the present application are within the protection scope of the present application. The protection scope of the present application is subject to the claims.

Claims

1. A runtime CPU fault-tolerant system based on heterogeneous computing, characterized in that: It includes a main process execution module, a checkpoint management module, a heterogeneous inspection module, a status comparison module, a scheduling and energy efficiency optimization module, and a system interaction module. The main process execution module plans the computational tasks of the target program's main process and divides the computational tasks into multiple execution segments that can be checked in parallel according to preset rules. The checkpoint management module creates checkpoints, providing the heterogeneous checking modules with the same execution starting point as the main process at a certain time. This allows the checking processes to reproduce the main process's execution from the starting point, thus enabling the checking of the main process's execution results. The heterogeneous inspection module utilizes the small cores of heterogeneous processors to execute inspection tasks in parallel, reproducing the execution logic of the main process to detect errors. The status comparison module compares the execution results of the main process and the inspection process to identify status differences caused by hardware failures. The scheduling and energy efficiency optimization module dynamically manages and checks the resource allocation of the process, performing core scheduling, frequency adjustment, and load balancing. The system interaction module handles the interaction between the program and the operating system, ensuring that the external behavior of the inspection process is consistent with that of the main process.

2. The runtime CPU fault-tolerant system based on heterogeneous computing according to claim 1, characterized in that: The checkpoint management module creates checkpoints, including: When the main process reaches a preset execution segment boundary, a copy of the main process is created using copy-on-write via relevant operating system interfaces. This copy is the checkpoint process. It also saves the current register state of the main process, including general-purpose registers, program counter PC, and stack pointer SP.

3. A runtime CPU fault-tolerant system based on heterogeneous computing according to claim 1, characterized in that it is heterogeneous. The inspection module utilizes hardware performance counters and breakpoint mechanisms to ensure that the inspection process reaches the same execution point as the main process, including: During the execution of the main process, when each checkpoint is reached, the number of branches executed in user mode within the current segment is recorded using a hardware performance counter. At the same time, the value of the current program counter (PC) is read to identify the execution point of the main process at the end of the current segment.

4. A runtime CPU fault-tolerant system based on heterogeneous computing according to claim 1, characterized in that: The state comparison module compares the execution results of the main process and the inspection process to identify state differences caused by hardware faults, including: locating the modified memory page within the execution segment through a soft dirty page mechanism or page mapping count; calculating the hash value of the dirty page data and comparing it with the hash value of the corresponding page in the main process; simultaneously verifying the register state; and triggering an error handling process when inconsistencies are found, terminating the program or recording a fault log.

5. A runtime CPU fault-tolerant system based on heterogeneous computing according to claim 4, characterized in that: When the state comparison module identifies modified memory pages within the execution segment, it tracks the modified memory pages during the execution of the main process and the checking process. The modified memory pages are called dirty pages. Different tracking methods are used for different architectures. In the x86_64 architecture, the Linux kernel's soft-dirty mechanism is used to identify modified pages through page table marking. In the AArch64 architecture, a custom PAGEMAP_SCAN interface is used to count page mappings and locate private modified pages.

6. A runtime CPU fault-tolerant system based on heterogeneous computing according to claim 1, characterized in that: When small cores are insufficient, the scheduling and energy efficiency optimization module migrates the tasks of the inspection process to large cores and avoids blocking the main process; it adjusts the frequency of small cores through dynamic voltage-frequency scaling (DVFS) to ensure that the inspection process is synchronized with the main process; and it monitors the load of each core to avoid resource waste or overload.

7. A runtime CPU fault-tolerant system based on heterogeneous computing according to claim 1, characterized in that: When the system interaction module handles the interaction between the program and the operating system, it intercepts and classifies system call operations, and adopts different processing strategies for different types of call operations. It also manages signal delivery, ensuring that external signals are executed at the same point in the main process and the checking process.

8. A runtime CPU fault-tolerance method based on heterogeneous computing, characterized by: The CPU fault tolerance of heterogeneous computing runtime is performed using a runtime CPU fault-tolerant system based on heterogeneous computing as described in any one of claims 1-7.

Images