An interrupt fault-tolerant and accelerated response method under a heterogeneous platform

Abstract

The application discloses a kind of interrupt fault tolerance and acceleration response method under heterogeneous platform, including, in interrupt service program, response accelerator message signal interrupt, read the first interrupt state indicating data transmission completion and the second interrupt state of user logic interrupt request, if both are no interrupt, be identified as user logic interrupt, increment kernel state interrupt count value, if second state has interrupt request, also increment count value, if the first state shows data transmission completion, then handle as data transmission interrupt;In application layer thread, obtain kernel state interrupt count value, compare with application layer processing count value, if kernel state count value is greater than application layer count value, send data to accelerator and increment application layer count value, if equal, thread hibernates first preset duration and retry, the application cooperates with application layer, solves interrupt loss problem, uses IOCTL polling acceleration response, and ensures system stability by intelligent hibernation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of heterogeneous computing and system communication, and particularly relates to a method for interrupt fault tolerance and accelerated response under a heterogeneous platform. BACKGROUND

[0002] With the increasing complexity of computing requirements, a heterogeneous computing platform that adopts a central processing unit (CPU) to work cooperatively with an accelerator such as a field programmable gate array (FPGA) and a graphics processing unit (GPU) has become a mainstream architecture for improving system performance. In such a platform, a peripheral component interconnect express (PCIE) bus has become a key channel for connecting a processor and an accelerator to perform high-speed data exchange, due to its high bandwidth and low latency. In order to achieve efficient asynchronous communication between the processor and the accelerator, a message signaled interrupt (MSI / MSI-X) mechanism is widely used, which directly submits an interrupt request to the processor through a data packet of a PCIE transaction layer, and significantly improves the efficiency and concurrency of interrupt processing, as compared with a traditional pin interrupt. In actual application, a typical interaction process is as follows: when the accelerator completes a certain task or needs the processor to intervene, a PCIE endpoint controller (EndPoint) of the accelerator triggers an MSI, which is received by a root complex of the processor, and then wakes up a driver in an operating system kernel to execute a corresponding interrupt service.

[0003] However, in actual system integration and application, such ideal interrupt communication process usually faces severe reliability and real-time challenges. On the one hand, the hardware logic of the PCIE core inside some accelerators (especially those using customized FPGA (Field-Programmable Gate Array) design) may have design defects, for example, the holding time of the interrupt request state signal is too short, causing the processor interrupt controller to fail to stably capture when reading the interrupt source, resulting in physical loss of the interrupt event, or lack of effective hardware handshaking mechanism, so that the accelerator cannot perceive the completion status of the processor side interrupt service, and may initiate the next interrupt request at an inappropriate time. On the other hand, the traditional software processing scheme also has fixed limitations. After receiving the interrupt, the kernel driver usually uses mechanisms such as waiting queue events (such as poll) or asynchronous signals (signal) to notify the upper application program. These mechanisms all rely on the complex process scheduling and context switching of the operating system, and in high-load or real-time requirement severe scenarios, unpredictable delays will be introduced. In addition, due to the superposition of hardware level signal loss and software level response delay, the interrupt processing chain will eventually be broken, which will cause user interrupt loss, data transmission failure, system throughput sharp decline, and even data consistency destruction and other serious problems. SUMMARY

[0004] This section is intended to summarize some aspects of the embodiments of the present application and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the abstract and title of the specification to avoid obscuring the purpose of this section, the abstract and the title, and such simplifications or omissions cannot be used to limit the scope of the present application.

[0005] In view of the above existing problems, the present application is proposed. Therefore, the present application provides an interrupt fault tolerance and acceleration response method under a heterogeneous platform to solve the problems proposed in the background art.

[0006] To solve the above technical problems, the present application provides the following technical scheme: an interrupt fault tolerance and acceleration response method under a heterogeneous platform, characterized in that, in the interrupt service program of the processor of the heterogeneous platform, the following is executed:

[0007] In response to the message signal interrupt received from the accelerator of the heterogeneous platform, reading a first interrupt state indicating completion of data transmission and a second interrupt state indicating user logic interrupt request;

[0008] When it is determined that the first interrupt state and the second interrupt state both indicate no interrupt occurrence, the current message signal interrupt is identified as a user logic interrupt, and an increment operation is performed on the kernel mode interrupt count value;

[0009] In the application layer thread of the heterogeneous platform processor, the following steps are executed:

[0010] The kernel interrupt count value is obtained;

[0011] The obtained kernel interrupt count value is compared with an application layer processing count value maintained by the application layer thread;

[0012] When the comparison result is that the kernel interrupt count value is greater than the application layer processing count value, data is sent to the accelerator, and an increment operation is performed on the application layer processing count value.

[0013] As a preferred solution of the method for interrupt fault tolerance and accelerated response under the heterogeneous platform, in the interrupt service program, if it is determined that the second interrupt state indicates that there is a user logic interrupt request, an increment operation is performed on the kernel interrupt count value.

[0014] As a preferred solution of the method for interrupt fault tolerance and accelerated response under the heterogeneous platform, in the interrupt service program, if it is determined that the first interrupt state indicates that the data transmission has been completed, the current message signal interrupt is processed as a data transmission completion interrupt.

[0015] As a preferred solution of the method for interrupt fault tolerance and accelerated response under the heterogeneous platform, the increment operation performed on the kernel interrupt count value is an atomic increment operation.

[0016] As a preferred solution of the method for interrupt fault tolerance and accelerated response under the heterogeneous platform, the step of obtaining the kernel interrupt count value is reading the kernel interrupt count value through an IOCTL interface as a non-blocking interface.

[0017] As a preferred solution of the method for interrupt fault tolerance and accelerated response under the heterogeneous platform, in the application layer thread, the following steps are further included:

[0018] When the comparison result is that the kernel interrupt count value is equal to the application layer processing count value, the application layer thread is put to sleep for a first preset time length, and then the step of obtaining the kernel interrupt count value is executed again.

[0019] As a preferred solution of the method for interrupt fault tolerance and accelerated response under the heterogeneous platform, after the data is sent to the accelerator and the increment operation is performed on the application layer processing count value, the following steps are further included:

[0020] The obtained current kernel interrupt count value is compared again with the incremented application layer processing count value;

[0021] If the result of the comparison again is that the kernel interrupt count value is still greater than the incremented application layer processing count value, the application layer thread sleeps for a second preset time length, and then the step of obtaining the kernel interrupt count value is executed again.

[0022] As a preferred scheme of the interrupt fault tolerance and accelerated response method under the heterogeneous platform, the value of the second preset time length is greater than the value of the first preset time length.

[0023] As a preferred scheme of the interrupt fault tolerance and accelerated response method under the heterogeneous platform, the first preset time length and the second preset time length are both user configurable parameters.

[0024] As a preferred scheme of the interrupt fault tolerance and accelerated response method under the heterogeneous platform, the first interrupt state is obtained by reading the value of the interrupt request register of the data transmission channel, and the second interrupt state is obtained by reading the value of the user interrupt request register.

[0025] Compared with the prior art, the beneficial effects of the scheme are:

[0026] 1. By setting the inference decision logic in the interrupt service program, that is, when a message signal interrupt is received but all interrupt status registers show invalid, it is actively determined as a valid user logic interrupt once and counted, without modifying any hardware design, the problem of premature cancellation of the interrupt signal caused by the accelerator PCIE core logic defect is effectively avoided, the stubborn disease of interrupt event loss is fundamentally solved, and the integrity and reliability of data interaction are guaranteed.

[0027] 2. The application layer thread directly polls the kernel interrupt count value through a non-blocking IOCTL interface, and compares it with the application layer processing count value maintained by itself, which replaces the traditional poll or signal notification mode depending on the operating system scheduling, bypasses the uncertainty delay caused by process context switching, enables the application layer to nearly real-time perceive the occurrence of the underlying interrupt, and thus realizes the millisecond or even microsecond response to the interrupt request, greatly improving the real-time performance of the system and the utilization rate of the PCIE bus bandwidth.

[0028] 3. In addition, the application also designs a flow control method of double dormancy time length in the application layer. In the scene of normal polling and detection of back-to-back interruption (i.e. new interruption occurs during processing the current interruption), different delay strategies are adopted, the frequency of data transmission can be intelligently adjusted according to the real-time density of interruption, the logical confusion or system crash caused by the impact of high-frequency DMA operation on the defective PCIE hardware core can be effectively avoided, and the scheme is good in hardware adaptability and application flexibility through parameter configurability. BRIEF DESCRIPTION OF DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the application, the drawings needed to be used in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor. Among them:

[0030] Figure 1 The interrupt service program execution flow chart of the interrupt fault tolerance and accelerated response method under the heterogeneous platform according to an embodiment of the application;

[0031] Figure 2 The application layer thread execution flow chart of the interrupt fault tolerance and accelerated response method under the heterogeneous platform according to an embodiment of the application;

[0032] Figure 3 The application layer accelerated response flow chart of the interrupt fault tolerance and accelerated response method under the heterogeneous platform according to an embodiment of the application. DETAILED DESCRIPTION

[0033] In order to make the above-mentioned purposes, features and advantages of the application more obvious and easy to understand, the specific embodiments of the application will be described in detail below with reference to the drawings of the specification. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor should be within the protection scope of the application.

[0034] In the following description, many specific details are set forth in order to provide a thorough understanding of the application, but the application can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without departing from the connotation of the application, therefore the application is not limited by the specific embodiments disclosed below.

[0035] Secondly, the "one embodiment" or "an embodiment" referred to herein means a specific feature, structure, characteristic, or combination of features and / or characteristics described herein that can be included in at least one implementation of the present application. The various appearances of "in one embodiment" or "an embodiment" in the specification do not all refer to the same embodiment, although they can.

[0036] The application is described in detail below in conjunction with the schematic drawings. In the detailed description of the embodiments of the application, the sectional views of the device structure are partially enlarged without the general scale for the convenience of illustration, and the schematic drawings are only examples, which should not limit the scope of protection of the application. In addition, the three-dimensional spatial dimensions of length, width and depth should be included in the actual manufacture.

[0037] Meanwhile, in the description of the application, it should be noted that the terms "upper, lower, inner and outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the application. In addition, the terms "first, second or third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0038] Unless otherwise expressly specified and limited, the terms "mounting, connecting, connection" in the application should be understood broadly, for example: it can be fixed connection, detachable connection or integral connection; it can also be mechanical connection, electrical connection or direct connection, it can also be indirectly connected through intermediate medium, or it can be the communication between two elements. For those skilled in the art, the specific meaning of the above terms in the application can be understood according to the specific circumstances.

[0039] Embodiment 1

[0040] Reference Figures 1 to 3 For the first embodiment of the application, the embodiment provides an interrupt fault tolerance and accelerated response method under a heterogeneous platform, comprising:

[0041] S1, in the interrupt service program of the heterogeneous platform processor, execute (reference Figure 1 ):

[0042] It should be noted that in the scheme of the present application, the execution entity is the operating system (Galaxy Kirin domestic operating system) kernel driver running on the processor (in this embodiment, Feiteng FT2000 / 4 CPU) of the domestic heterogeneous platform. After the driver is successfully initialized and maps the PCIE configuration space and BAR (Base Address Register) space of the accelerator (domestic Fudan micro FMQL45 FPGA), it registers a special message signal interrupt (MSI) processing function, i.e. interrupt service program (ISR), with the kernel. When the FPGA sends an MSI package to the CPU through the PCIE bus, the ISR is automatically called. The accelerator and the processor are connected through the PCIE bus, the CPU end is the root complex (Root Complex, RC), and the FPGA end is the end point device (EndPoint, EP).

[0043] It should be explained that the BAR space refers to the address space mapped by the base address register (Base Address Register) in the PCI device. Each PCI device has multiple BARs, which are used to indicate the location of the device in the system address space.

[0044] Specifically, the execution flow inside the ISR is divided into interrupt source state reading, hierarchical discrimination and fault tolerance decision of the interrupt source, and atomic increment of the interrupt count value in the kernel mode.

[0045] S101, in response to the message signal interrupt received from the heterogeneous platform accelerator, reading a first interrupt state for indicating data transmission completion and a second interrupt state for indicating user logic interrupt request;

[0046] Further, for interrupt source state reading, the primary task of the program is to immediately determine the specific source of the interrupt as soon as it enters the ISR. Since the execution environment of the ISR requires very high efficiency and prohibits any operation that may cause blocking, we use the memory mapping I / O (MMIO) method to directly and quickly access the hardware register on the FPGA side through the pre-mapped BAR space address. The specific operation is as follows:

[0047] By reading the first interrupt state (DMA interrupt state), that is, the program initiates a read operation to a specific offset address of the FPGA's DMA engine control logic area, which corresponds to the DMA channel transmission completion interrupt request register. At the driver code level, this can be implemented through a function similar to ioread32(dma_channel_int_reg_addr). The read 32-bit integer value is temporarily stored as the state value channel_int_request. According to the design of the FPGA-side PCIE core, if this value is non-zero, it indicates that at least one DMA channel has completed the data transmission task; if it is zero, it indicates that there is no DMA completion event.

[0048] By reading the second interrupt state (user logic interrupt state), that is, the program initiates another read operation to a specific offset address of the FPGA's user logic interface area, which corresponds to the user interrupt request register. Similarly, this can be implemented through the ioread32(user_irq_reg_addr) function, and the read value is temporarily stored as the state value usr_irq_req. If this value is non-zero, it indicates that the user application logic on the FPGA (such as the radar signal processing module) is requesting CPU intervention; if it is zero, it indicates that there is currently no explicit user interrupt request.

[0049] Further, for hierarchical discrimination and fault tolerance decision of the interrupt source, after obtaining the two state values channel_int_request and usr_irq_req, the ISR also executes an if-else decision logic with priority. This decision logic not only handles normal situations, but also embeds a hardware defect tolerance mechanism. This tolerance mechanism is divided into three cases:

[0050] Case one: DMA interrupt priority processing, represented by if(channel_int_request!=0), which is the highest priority condition. If channel_int_request is not zero, regardless of the value of usr_irq_req, the ISR will classify the current interrupt as a data transmission completion interrupt. This is because in system design, the completion of DMA transmission is a key event that needs to be handled immediately. At this time, the ISR will immediately execute the corresponding processing flow, such as clearing the DMA interrupt flag, waking up the process waiting for DMA completion, releasing the related memory buffer, etc. In this case, the kernel interrupt count value will not be increased, because the root cause of this interrupt is data transmission, not user logic request. Only after processing is completed, the ISR returns normally;

[0051] Case two: normal user interrupt handling, its condition is expressed as else if (usr_irq_req!= 0), only after excluding the possibility of DMA interrupt, the program will check usr_irq_req, if the value is not zero, it indicates that this is a standard, state flag is successfully captured user logic interrupt, consistent with the expected workflow, at this time, the ISR will identify that this is a valid user request, and needs to inform the application layer;

[0052] Case three: inferred user interrupt fault-tolerant processing, if the execution flow of the program goes to this branch, it means that channel_int_request is zero and usr_irq_req is also zero, on the surface, there is an interrupt signal (MSI), but there is no interrupt source state; at this time, the traditional method may ignore it or record it as an error, but the present application will perform an inferred decision here, which is based on the premise that the physical arrival of the MSI signal is a fact, and the program infers that this must be triggered by a user logic interrupt, but due to the design defects of the FPGA PCIE core, the usr_irq_req state bit has been prematurely hardware cleared before the CPU's ISR has a chance to read it, therefore, even without direct register evidence, the ISR will identify the current message signal interrupt as a valid, but state lost user logic interrupt;

[0053] S102、When it is determined that the first interrupt state and the second interrupt state both indicate that no interrupt occurs, the current message signal interrupt is identified as a user logic interrupt, and an increment operation is performed on the kernel interrupt count value;

[0054] Further, for the atomic increment of the kernel interrupt count value, cases two and three in the above decision logic, that is, any event identified as (whether normally captured or inferred) a user logic interrupt, the ISR will perform a core action: incrementing a kernel interrupt count value (kernel_interrupt_count) defined in the global scope of the driver program;

[0055] In addition, in order to ensure data consistency in complex scenarios such as multi-core CPU concurrent execution or interrupt nesting, the counter variable is usually defined as atomic_t type in the Linux kernel, and its increment operation must be completed through a special atomic function, such as calling the atomic increment function atomic_inc(&kernel_interrupt_count), to ensure that even if multiple user interrupts occur in a very short time, each interrupt will be reflected as an increase in the count value without omission and only once, thus eliminating the counting error caused by race conditions;

[0056] Specifically, the above interrupt decision process and counting logic process are expressed by mathematical formulas as follows:

[0057]

[0058] wherein, represents the kernel interrupt count value before ISR execution, represents the kernel interrupt count value after ISR execution, S1 represents the Boolean value of the first interrupt state channel_int_request (1 is valid, and 0 is invalid), and S2 represents the Boolean value of the second interrupt state usr_irq_req (1 is valid, and 0 is invalid); represents an and operation, also called an “and” operation, and similarly, represents an or operation, also called an “or” operation;

[0059] It should be noted that through the above steps, the scheme of the present application can ensure that every real user interrupt intention can be accurately converted into the accumulation of the kernel interrupt count value (kernel_interrupt_count) in the case of unreliable hardware behavior, and the accumulated count value is a reliable and non-delayed beacon connecting the underlying hardware event and the upper application program.

[0060] S2, in the application layer thread of the heterogeneous platform processor, execute (refer to Figure 2 and Figure 3 ):

[0061] It should be noted that this step is the “nerve center” connecting the underlying hardware event and the upper business logic, and its execution entity, i.e., the “radar information data sending thread”, is designed as a high-priority real-time work thread in the scheme of the present application, and once started, it enters an endless while loop, which is mainly responsible for “monitoring” the kernel_interrupt_count count value generated by the kernel driver in step S1. In order to achieve this goal, the thread maintains a state variable, i.e., an application layer processing count value (application_processing_count), which is set to 0 at the initialization of the main program, and at the same time, the latest kernel_interrupt_count is obtained before the thread while loop and is assigned to the variable. The physical meaning is that the total number of user interrupts that have been successfully responded to and completed by the thread since its startup, and therefore, this step is equivalent to a loop mechanism, which constantly and efficiently synchronizes the kernel_interrupt_count and application_processing_count count values in the kernel mode and the user mode, respectively.

[0062] It should be noted that in the actual debugging process, since the application program may exist multiple times of closing and restarting, after restarting, the initialization value of application_processing_count is 0, and the kernel_interrupt_count of the underlying kernel may not be 0, so before the while loop, the two count values (kernel_interrupt_count and application_processing_count) need to be synchronized;

[0063] Specifically, the loop mechanism is divided into a lock-free kernel state acquisition, an interrupt discrimination based on the difference between the count values, and a "poll-sleep" strategy considering response and efficiency;

[0064] S201, acquire the kernel interrupt count value;

[0065] Further, for the lock-free kernel state acquisition, the sub-step is an information input link, at this time, the primary task of the thread is to acquire the latest value of kernel_interrupt_count from the kernel driver; and the present application discards all communication models relying on the operating system scheduler for blocking-waking, such as traditional poll, select, epoll or signal, and the fundamental defect of these traditional models is that when an interrupt occurs, there is an uncontrollable delay between the wake-up signal sent from the kernel and the application thread being selected by the scheduler and resuming running, which varies with system load; therefore, in order to eliminate the delay problem, the present application scheme adopts a more direct and determined communication way, that is, a non-blocking IOCTL (Input / Output Control) interface, which is implemented as follows:

[0066] In the kernel driver program, a unique IOCTL command code is defined, for example IOCTL_XDMA_GET_INTS, and the driver program will implement a function specially processing the command;

[0067] When the application layer thread starts each iteration of its while loop, it will call ioctl system and send the above IOCTL_XDMA_GET_INTS command to the opened device file descriptor, and pass in a user space memory address for receiving the count value;

[0068] When the IOCTL processing function in the driver program is triggered, the current value of the kernel_interrupt_count of the atomic_t type maintained internally is directly read, and then the copy_to_user() function is used to copy the value to the memory address passed in by the application layer.

[0069] It should be noted that, since the process of adopting the non-blocking IOCTL interface does not involve any waiting, locking or operations that may cause sleep, it will be completed and returned immediately after the application layer ends through the ioctl system call, almost equivalent to the overhead of a function call; therefore, in this way, the application layer thread can take snapshot sampling of the interrupt count value of the kernel at a very high frequency (theoretically up to tens of thousands or even hundreds of thousands per second), thus ensuring the real-time nature of information acquisition;

[0070] S202, compare the obtained kernel interrupt count value with the application layer processing count value maintained by the application layer thread;

[0071] Further, for the interrupt discrimination based on the difference in count value, this sub-step is the decision-making link. After obtaining the latest snapshot value of kernel_interrupt_count (denoted as K_count), the thread will immediately perform mathematical comparison between it and the application_processing_count (denoted as A_count) maintained by itself. The result of the comparison directly determines the next behavior of the thread. Among them, the first discrimination condition is represented as: K_count>A_count, which has the physical meaning that since the last time the application layer processed the interrupt, the interrupt service program (ISR) of the kernel has been triggered at least once, in other words, the production speed of the kernel exceeds the consumption speed of the application, and there is a new interrupt to be processed. For example, if the current K_count=105 and A_count=104, it indicates that the 105th user interrupt has occurred, and the application layer has not responded to it;

[0072] Further, once the first discrimination condition is met, it is determined that there is a new interrupt, at this time, the normal flow of the while loop will be changed, and the thread will immediately jump to execute data sending and subsequent processing. Among them, the second decision condition is represented as K_count==A_count, which has the physical meaning that the application layer has completely processed all the interrupts recorded by the kernel, and the production speed of the kernel and the consumption speed of the application have reached synchronization, and the current system is in the "interrupt silent" period. Once the second discrimination condition is met, it is determined that there is no new interrupt, and the thread will not perform any business operation, but will enter the sub-step of the "poll-sleep" strategy that takes into account response and efficiency, and will enter short sleep to avoid resource waste;

[0073] Further, for the "poll-sleep" strategy which balances response and efficiency, the sub-step is an efficiency optimization link, when the above-mentioned loop of the lock-free kernel state acquisition sub-step and the interrupt discrimination sub-step based on the difference in the count value is continuously carried out without any delay (i.e. busy waiting), when the system has no interrupt for a long time, the thread will occupy a CPU core, causing great waste of resources, therefore, after discrimination that there is no new interrupt, the thread must be suspended for a short time by itself;

[0074] Specifically, the thread calls the usleep(T_sleep1) function, wherein T_sleep1 is a first preset time length, which is a user configurable hyperparameter, for example, 5 microseconds; the function is that the thread voluntarily gives up the CPU execution right for T_sleep1, in this period of time, the CPU can be scheduled to execute other tasks, then when the sleep ends, the thread is automatically woken up and immediately returns to the starting point of the while loop to start a new round of "acquisition-comparison" cycle, i.e. the above-mentioned sequence of the lock-free kernel state acquisition sub-step and the interrupt discrimination sub-step based on the difference in the count value;

[0075] In addition, it should be noted that in the present application, the value of T_sleep1 is a key trade-off point, the smaller the value, the lower the response delay of the new interrupt, but the greater the idle overhead of the CPU; the larger the value, the higher the CPU efficiency, but the interrupt response delay in the worst case will also increase accordingly, so in the present application, it is set as a configurable parameter, so that the present application can be flexibly adapted according to the real-time requirements of different hardware platforms and application scenarios;

[0076] S203, when the comparison result is that the kernel interrupt count value is greater than the application layer processing count value, data is sent to the accelerator, and an increment operation is performed on the application layer processing count value;

[0077] Further, when a new interrupt occurs (i.e. K_count>A_count), first, the thread calls the write system to send the prepared data packet (such as radar information data) to the FPGA through the corresponding device node (such as / dev / xdma0_h2c_0), which is a standard DMA write operation; after the write system call returns successfully, the thread immediately performs a +1 operation on the application_processing_count maintained by itself to indicate that the application layer has successfully responded to this interrupt and completed the corresponding processing;

[0078] Further, in order to prevent logic confusion caused by the application layer responding too quickly and continuously initiating high-frequency DMA write operations to the defective FPGA PCIE core, the application also designs a back pressure mechanism, which is triggered after the above-mentioned application_processing_count execution +1 operation step is executed.

[0079] Further, after the application_processing_count is incremented, the thread again compares the obtained kernel_interrupt_count with the updated application_processing_count (denoted as A_count_new).

[0080] Specifically, case one (catch up with the kernel): if K_count == A_count_new, it indicates that no new interrupt occurs during this processing period, the system recovers synchronization, and the thread will directly return to the loop starting point of S2 step to start the next round of normal polling (accompanied by T_sleep1 sleep).

[0081] Specifically, case two (still lagging behind the kernel): if K_count > A_count_new, it indicates that at least one new interrupt (i.e., back-to-back interrupts) is initiated by the FPGA within a very short time of processing the previous interrupt by the thread, and in order to avoid sending data to impact the hardware immediately, the thread will call usleep(T_sleep2) to sleep for a longer time, wherein the value of the second preset time T_sleep2 (such as 20 microseconds) needs to be greater than T_sleep1, which is also configurable by the user; since this longer sleep provides a buffer time for the FPGA DMA logic, it avoids the FPGA logic confusion caused by high-frequency DMA data transmission, so after the sleep is over, the thread will return to the loop starting point of S2 step.

[0082] It should be noted that through the cooperative design of the kernel layer and the application layer, the application not only solves the problem of interrupt loss caused by hardware defects through fault tolerance decision, but also bypasses the delay of traditional kernel-application layer communication through an efficient IOCTL polling mechanism, realizes fast response to interrupts, and at the same time guarantees the stability of the system through an intelligent sleep strategy.

[0083] Those skilled in the art will appreciate that embodiments of the present application can be readily used as a method, apparatus, or computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer readable storage media (including, but not limited to, disk memory, CD-ROMs, optical storage devices, etc.) embodying computer readable program code. Embodiments of the present application can be implemented in various computer languages, including, but not limited to, object oriented programming languages such as Java and direct script languages such as JavaScript.

[0084] The present application is described in reference to the flowchart illustrations and / or block diagrams according to the embodiments of the application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams.

[0085] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams.

[0086] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams.

[0087] While preferred embodiments of the application have been described, modifications and alterations thereto will occur to those skilled in the art upon reading the preceding description. In particular, it will be apparent to those skilled in the art that parts and materials can be substituted for other parts and materials without departing from the scope of the present application. Therefore, it is the intent that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art.

[0088] Obviously, numerous modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A method for interrupt fault tolerance and accelerated response on a heterogeneous platform, characterized in that, Within the interrupt service routine of the heterogeneous platform processor, execute: In response to an interruption of a message signal received from a heterogeneous platform accelerator, read a first interrupt status indicating the completion of data transmission and a second interrupt status indicating a user logic interruption request. When both the first interrupt status and the second interrupt status indicate that no interrupt has occurred, the current message signal interrupt is identified as a user logic interrupt, and the kernel interrupt count is incremented. Within the application-layer thread of a heterogeneous platform processor, the following is executed: Obtain the kernel-mode interrupt count value; The obtained kernel-mode interrupt count value is compared with the application-layer processing count value maintained by the application-layer thread. When the comparison result shows that the kernel interrupt count is greater than the application layer processing count, data is sent to the accelerator, and the application layer processing count is incremented.

2. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 1, characterized in that, The interrupt service routine also includes: if it is determined that the second interrupt status indicates the existence of a user logic interrupt request, then incrementing the kernel-mode interrupt count value.

3. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 1 or 2, characterized in that, The interrupt service routine also includes: if it is determined that the first interrupt status indicates that the data transmission has been completed, then the current message signal interruption is treated as a data transmission completion interruption.

4. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 2, characterized in that, The increment operation performed on the kernel interrupt count value is an atomic increment operation.

5. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 1, characterized in that, The step of obtaining the kernel interrupt count value is as follows: read the kernel interrupt count value through an IOCTL interface, which is a non-blocking interface.

6. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 1, characterized in that, Within the application layer thread, it also includes: When the comparison result shows that the kernel interrupt count value is equal to the application layer processing count value, the application layer thread sleeps for a first preset time, and then executes the step of obtaining the kernel interrupt count value again.

7. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 6, characterized in that, After sending data to the accelerator and incrementing the count value processed by the application layer, the process further includes: The currently acquired kernel-mode interrupt count value is compared again with the incremented application-layer processing count value; If the result of the comparison is that the kernel interrupt count is still greater than the incremented application layer processing count, the application layer thread sleeps for a second preset duration, and then executes the step of obtaining the kernel interrupt count again.

8. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 7, characterized in that, The value of the second preset duration is greater than the value of the first preset duration.

9. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 8, characterized in that, Both the first preset duration and the second preset duration are user-configurable parameters.

10. The interrupt fault tolerance and accelerated response method under heterogeneous platforms as described in claim 1, characterized in that, The first interrupt status is obtained by reading the value of the interrupt request register of the data transmission channel, and the second interrupt status is obtained by reading the value of the user interrupt request register.

Images