Interrupt processing method and apparatus, electronic device, and storage medium

Abstract

The application provides an interrupt processing method and device, electronic equipment and a storage medium. The method is applied to a device including a master processor and a slave processor, the master processor and the slave processor are configured to mask hardware interrupt responses, and peripheral interrupt is configured to be sent to the master processor; the method includes: monitoring an interrupt controller; in response to monitoring a to-be-processed interrupt, and the to-be-processed interrupt being bound to the master processor, determining whether the to-be-processed interrupt is a peripheral interrupt or an inter-core interrupt; if the to-be-processed interrupt is determined to be a peripheral interrupt, selecting a slave processor as a target processor, sending an inter-core interrupt to the target processor, and enabling the target processor to process a peripheral interrupt notified by the inter-core interrupt; and if the to-be-processed interrupt is determined to be an inter-core interrupt, notifying the interrupt controller that the peripheral interrupt has been processed. The method can improve the response speed of interrupt processing.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to interrupt handling methods, apparatus, electronic devices, and storage media. Background Technology

[0002] In scenarios with extremely high real-time requirements, such as CNC machine tools, robots, and semiconductor equipment, the response latency to peripheral signals is typically required to be no more than 1 microsecond. Traditional operating system interrupt handling mechanisms involve multiple stages, including hardware interrupt signal transmission, processor exception state switching, operating system context saving and restoration, and bus access latency, resulting in an overall response latency generally on the order of several microseconds, which is insufficient to meet the requirements of these scenarios.

[0003] In existing technologies, while the Poll Mode Driver (PMD) of the Data Plane Development Kit (DPDK) or the New API (NAPI) of Linux avoids traditional interrupt latency by actively polling peripheral registers, they are only applicable to specific peripherals and lack system-level versatility. Furthermore, polling still requires traversing the system bus, and bus contention leads to uncontrollable latency. The system register interface introduced in ARM's Generic Interrupt Controller version 3 (GICv3) can shorten the latency of accessing the interrupt controller, but it does not change the overall process of traditional interrupt triggering. In addition, inter-core interrupts and shared memory communication in multiprocessor systems are still limited by traditional mechanisms, and the latency problem remains unresolved.

[0004] Therefore, there is an urgent need for an interrupt handling method that can improve response speed. Summary of the Invention

[0005] In view of this, this application provides an interrupt handling method, apparatus, electronic device, and storage medium that can improve the response speed of interrupt handling.

[0006] To solve the above-mentioned technical problems, the technical solution of this application is implemented as follows:

[0007] In one embodiment, an interrupt handling method is provided, applied to a device including a master processor and a slave processor, wherein the master processor and the slave processor are configured to mask hardware interrupt responses, and peripheral interrupts are configured to be sent to the master processor; the method includes:

[0008] Monitor the interrupt controller;

[0009] In response to the detection of a pending interrupt that is bound to the main processor, it is determined whether the pending interrupt is a peripheral interrupt or an inter-core interrupt.

[0010] If the interrupt to be processed is determined to be a peripheral interrupt, then select one of the slave processors as the target processor and send an inter-core interrupt to the target processor so that the target processor can process the peripheral interrupt notified by the inter-core interrupt;

[0011] If the interrupt to be processed is determined to be an inter-core interrupt, the interrupt controller is notified that the peripheral interrupt has been processed.

[0012] The target processor is a slave processor that is in an idle state;

[0013] Selecting one of the slave processors as the target processor includes:

[0014] Select a slave processor that is currently in an idle state as the target processor;

[0015] If there are multiple idle slave processors, one of them will be selected according to preset rules.

[0016] in,

[0017] When sending an inter-core interrupt signal to the target processor, the method further includes:

[0018] The main processor controls the target processor to mark its state as non-idle.

[0019] When the interrupt controller is notified that the peripheral interrupt has been processed, the method further includes:

[0020] The main processor controls the target processor to mark its state as idle.

[0021] The method further includes, when any of the following conditions are met: continuing to monitor the interrupt controller:

[0022] No pending interrupts were detected when monitoring the interrupt controller;

[0023] The detected interrupts to be processed are neither peripheral interrupts nor inter-core interrupts;

[0024] The detected interrupt to be processed is a peripheral interrupt, and there is currently no slave processor in an idle state;

[0025] The target processor is marked as being in a non-idle state;

[0026] The target processor is marked as being in an idle state.

[0027] The method further includes:

[0028] In response to the detection of a pending interrupt that is bound to the slave processor, it is determined whether the pending interrupt is an inter-core interrupt.

[0029] In response to the interrupt to be processed being an inter-core interrupt, process the peripheral interrupt notified by the inter-core interrupt;

[0030] When the peripheral interrupt handling of the inter-core interrupt notification is completed, an inter-core interrupt is sent to the main processor to notify the corresponding peripheral interrupt handling is complete.

[0031] The method further includes, when any of the following conditions are met: continuing to monitor the interrupt controller:

[0032] No pending interrupts were detected when monitoring the interrupt controller;

[0033] The detected pending interrupts are not inter-core interrupts;

[0034] The peripheral interrupt indicated by the inter-core interrupt has been processed.

[0035] In another embodiment, an interrupt handling apparatus is provided, characterized in that it is applied to a device including a master processor and a slave processor, wherein the master processor and the slave processor are configured to mask hardware interrupt responses, and peripheral interrupts are configured to be sent to the master processor; the apparatus includes:

[0036] The monitoring unit is used to monitor the interrupt controller;

[0037] The judgment unit is used to determine whether the interrupt to be processed is a peripheral interrupt or an inter-core interrupt in response to the detection of an interrupt to be processed and the interrupt to be processed is bound to the main processor.

[0038] The processing unit is configured to select one of the slave processors as the target processor if it is determined that the interrupt to be processed is a peripheral interrupt;

[0039] The sending unit is used to send an inter-core interrupt to the target processor so that the target processor can process the peripheral interrupt notified by the inter-core interrupt; if it is determined that the interrupt to be processed is an inter-core interrupt, the interrupt controller is notified that the peripheral interrupt has been processed.

[0040] The judgment unit is further configured to, in response to detecting a pending interrupt and the pending interrupt being bound to the slave processor, determine whether the pending interrupt is an inter-core interrupt;

[0041] The processing unit is further configured to process the peripheral interrupt notification of the inter-core interrupt in response to the interrupt to be processed being an inter-core interrupt;

[0042] The sending unit is further configured to send an inter-core interrupt to the main processor to notify the corresponding peripheral interrupt processing is complete when the peripheral interrupt processing of the inter-core interrupt notification is completed.

[0043] In another embodiment, an electronic device is provided, comprising:

[0044] Multiple processors;

[0045] An interrupt controller, which is connected to the plurality of processors via a system bus;

[0046] A memory that stores a computer program, which implements an interrupt handling method when executed by the processor.

[0047] In another embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements an interrupt handling method.

[0048] As can be seen from the above technical solution, in the above embodiments, hardware interrupts are masked on the master and slave processors. When a peripheral interrupt bound to the master processor is actively detected by software, a slave processor is selected and the corresponding slave processor is notified through inter-core interrupts to handle the peripheral interrupt. When an inter-core interrupt bound to the master processor is detected, the interrupt controller is notified that the corresponding peripheral interrupt has been processed. This software-based interrupt handling method based on the operating system avoids time-consuming steps such as hardware signal transmission and processor abnormal state switching in the traditional interrupt path. At the same time, it achieves efficient task distribution among multiple processors through the inter-core interrupt mechanism, which can improve the response speed of interrupt handling. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0050] Figure 1 This is a schematic diagram of the interrupt architecture;

[0051] Figure 2 This is a schematic diagram of an interrupt handling process on the main processor side in an embodiment of this application;

[0052] Figure 3 This is a schematic diagram of another interrupt handling process on the main processor side in an embodiment of this application;

[0053] Figure 4 This is a schematic diagram of an interrupt handling process from the processor side in an embodiment of this application;

[0054] Figure 5 This is a schematic diagram of the interrupt handling process in an embodiment of this application;

[0055] Figure 6 This is a schematic diagram of the interrupt handling device structure in an embodiment of this application;

[0056] Figure 7 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0057] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe the order or sequence of objects. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0059] The technical solution of the present invention will be described in detail below with reference to specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0060] Interrupt handling in related technologies is based on hardware or a combination of hardware and software. Due to hardware limitations, interrupt handling response speed is too slow and latency is a serious problem.

[0061] To address the aforementioned issues, this application provides an interrupt handling method applied to a device including a master processor and slave processors. The method involves configuring the master and slave processors to disable hardware interrupt responses, actively monitoring pending interrupts in the interrupt controller using operating system-based software, and handling the interrupt according to the role of the processor bound to it, as well as inter-core communication. This operating system-based software-implemented interrupt handling method avoids time-consuming steps such as hardware signal transmission and processor abnormal state switching in traditional interrupt paths. Furthermore, it achieves efficient task distribution among multiple processors through an inter-core interrupt mechanism, thereby improving the interrupt handling response speed.

[0062] This application can be applied to devices that include a single physical processor or multiple physical processors. If there are multiple physical processors, each physical processor may include one or more cores; if there is a single physical processor, it includes multiple cores. That is, the smallest unit of processor involved in this application is a core. For ease of description, this application will uniformly refer to it as a processor, which can be a core or a single physical processor. One processor in the multi-processor configuration is the master processor, and the other processors are slave processors. The processor here can be a Central Processing Unit (CPU), a Microcontroller Unit (MCU), etc.

[0063] The embodiments in this application employ a software-based approach within the operating system to handle interrupts, without altering the hardware architecture. See also... Figure 1 , Figure 1 This is a schematic diagram of the interrupt architecture. Figure 1 Taking a three-processor, three-peripheral configuration as an example, the three processors are processor 1, processor 2 and processor 3; the three peripherals are peripheral 1, peripheral 2 and peripheral 3.

[0064] Each peripheral device is connected to the interrupt controller via an interrupt signal line, allowing interrupt signals to be sent to the interrupt controller. It is also connected to the processor via the system bus.

[0065] Interrupt controller: Responsible for collecting all interrupt information, including interrupts from peripherals and inter-core interrupts from the processor, and then sending them to the bound processor for processing according to the interrupt routing settings. There is also a bus connection between the interrupt controller and the processor, and the processor can read and write the relevant registers of the interrupt controller through the bus.

[0066] Each processor, in existing implementations, is responsible for interrupt handling. Upon receiving an interrupt signal, it enters an abnormal state, performs interrupt-related processing, and then returns to the state before the interrupt was triggered. In this embodiment, each processor needs to be configured to disable hardware interrupt responses in its implementation. That is, upon receiving an interrupt signal, it does not process it but actively monitors for pending interrupts through software and handles them via software control. Configuring hardware interrupt masking on the processor can be achieved by modifying the processor's interrupt control status bits, preventing some or all interrupt sources from being responded to. In this embodiment, at least peripheral interrupts and inter-core interrupts are not responded to. This application does not restrict the existence or handling of other interrupts; therefore, in specific implementations, peripheral interrupts and inter-core interrupts can be masked, or all interrupts can be masked.

[0067] The peripheral interrupt triggering process: When the peripheral chip or circuit meets certain conditions, it will notify the interrupt controller through the connection line between the peripheral and the interrupt controller, and the interrupt controller will then notify the corresponding processor. In this application, all peripheral interrupts are configured to be sent to the main processor. Therefore, the interrupt controller will notify the main processor of all peripheral interrupts, and the slave processor will not receive peripheral interrupts.

[0068] Inter-core interrupt triggering process: When a processor needs to notify another processor to perform related processing, the relevant implementation will write the corresponding register of the interrupt controller through the system bus, and then the interrupt controller will notify the corresponding processor to perform processing; however, in this embodiment, the inter-core interrupt is sent through software control.

[0069] As described above, the operations of generating and sending peripheral interrupts to the processor remain unchanged. The difference is that when the processor receives a peripheral interrupt, it does not process these peripheral interrupts because the hardware interrupt handling is disabled. In practice, these interrupts can be ignored or discarded.

[0070] In practical implementation, a master processor needs to be configured, and the other processors are slave processors. This application does not restrict which processor is configured as the master processor and which as the slave processor among multiple processors. For example, processor 1 can be configured as the master processor and processors 2 and 3 as slave processors.

[0071] In practical implementation, the software code is run on the processor, and different implementation logic code is run on the main processor and the slave processor to implement the interrupt handling of this application.

[0072] The process of implementing interrupt handling in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0073] See Figure 2 , Figure 2This is a schematic diagram of an interrupt handling process on the main processor side in an embodiment of this application. The specific steps are as follows:

[0074] Step 201: Monitor the interrupt controller.

[0075] The monitoring of the interrupt controller here involves reading the interrupt status register of the interrupt controller to determine whether there are any pending interrupts.

[0076] Step 202: In response to the detection of a pending interrupt that is bound to the main processor, determine whether the pending interrupt is a peripheral interrupt or an inter-core interrupt.

[0077] Step 203: If the interrupt to be processed is determined to be a peripheral interrupt, then select a slave processor as the target processor and send an inter-core interrupt to the target processor so that the target processor can process the peripheral interrupt notified by the inter-core interrupt. End this process.

[0078] In this embodiment, when using inter-core interrupt notifications to handle peripheral interrupts, the inter-core interrupt number and the peripheral interrupt number are typically bound together. Knowing the inter-core interrupt number allows the identification of the peripheral terminal to which the inter-core interrupt number is being notified. For example, in the ARMv8 architecture: inter-core interrupt numbers are 0-15, with 0-7 typically reserved for the operating system; peripheral interrupt numbers are 32-1024. However, there aren't many peripheral interrupts with high requirements and high usage frequency. Therefore, these peripheral interrupt numbers can be mapped one-to-one with the inter-core interrupt numbers of the inter-core interrupts. For example, inter-core interrupt number 3 and peripheral interrupt number 32. Thus, when the inter-core interrupt number received from the processor is 3, the handler corresponding to peripheral interrupt number 32 is processed. This is merely an example; specific implementations are not limited to this approach.

[0079] Step 204: If it is determined that the interrupt to be processed is an inter-core interrupt, then notify the interrupt controller that the peripheral interrupt has been processed.

[0080] In this embodiment, the master and slave processors disable hardware interrupts. When a peripheral interrupt bound to the master processor is actively detected via software, a slave processor is selected, and the corresponding slave processor is notified to handle the peripheral interrupt through an inter-core interrupt. Upon detecting an inter-core interrupt bound to the master processor, the interrupt controller is notified that the corresponding peripheral interrupt has been processed. This embodiment avoids time-consuming steps such as hardware signal transmission and processor abnormal state switching in traditional interrupt paths. Furthermore, the inter-core interrupt mechanism enables efficient task distribution among multiple processors, improving the response speed of interrupt handling.

[0081] See Figure 3 , Figure 3This is a schematic diagram of another interrupt handling process on the main processor side in an embodiment of this application. The specific steps are as follows:

[0082] Step 301: Monitor the interrupt controller.

[0083] The monitoring of the interrupt controller here involves reading the interrupt status register of the interrupt controller to determine whether there are any pending interrupts.

[0084] If no pending interrupt is detected, continue monitoring the interrupt controller.

[0085] Step 302: In response to the detection of a pending interrupt and the fact that the pending interrupt is bound to the main processor, determine whether the pending interrupt is a peripheral interrupt or an inter-core interrupt.

[0086] Step 303: If the interrupt to be processed is determined to be a peripheral interrupt, then select a slave processor in an idle state as the target processor, send an inter-core interrupt to the target processor, so that the target processor can process the peripheral interrupt notified by the inter-core interrupt, and control the master processor to mark the target processor's state as non-idle. End this process.

[0087] The processing of the currently detected pending interrupts (peripheral interrupts) is temporarily terminated here. The status is marked and the interrupt controller is monitored again.

[0088] Before selecting an idle slave processor as the target processor, it is necessary to first determine whether there is an idle slave processor. If so, select one of the idle slave processors as the target processor; otherwise, do not process the peripheral interrupt for the time being, and continue to monitor the interrupt controller until a non-idle slave processor is released, and then process the peripheral interrupt.

[0089] Step 304: If it is determined that the interrupt to be processed is an inter-core interrupt, then the interrupt controller is notified that the corresponding peripheral interrupt has been processed and the main processor is controlled to mark the target processor's state as idle.

[0090] The processing of the currently detected interrupts (inter-core interrupts) is temporarily terminated here, and the status is marked before monitoring the interrupt controller again.

[0091] In this embodiment, the master and slave processors disable hardware interrupts. When a peripheral interrupt bound to the master processor is actively detected via software, an idle slave processor is selected, and the corresponding slave processor is notified to handle the peripheral interrupt via an inter-core interrupt, and the state of the slave processor is updated. When an inter-core interrupt bound to the master processor is detected, the interrupt controller is notified that the corresponding peripheral interrupt has been processed, and the master processor is controlled to update the state of the slave processor. This embodiment avoids the time-consuming steps of hardware signal transmission and processor abnormal state switching in traditional interrupt paths. At the same time, the inter-core interrupt mechanism enables efficient task distribution among multiple processors, which can improve the response speed of interrupt handling.

[0092] In one example, interrupt controller monitoring continues on the main processor side if any of the following conditions are met:

[0093] No pending interrupts were detected when monitoring the interrupt controller;

[0094] The detected interrupts to be processed are neither peripheral interrupts nor inter-core interrupts;

[0095] The target processor is marked as non-idle.

[0096] The target processor is marked as idle.

[0097] See Figure 4 , Figure 4 This is a schematic diagram of an interrupt handling process from the processor side in an embodiment of this application. The specific steps are as follows:

[0098] Step 401: Monitor the interrupt controller.

[0099] Step 402: In response to the detection of a pending interrupt and the fact that the pending interrupt is bound to a slave processor, it is determined whether the pending interrupt is an inter-core interrupt.

[0100] In this embodiment, if the processor detects that the interrupt to be processed is not an inter-core interrupt, it will not process it and will continue to monitor. In other words, this embodiment does not pay attention to or process interrupts that may be caused by abnormalities or other types of interrupts. If it is another type of interrupt, it can be processed according to its relevant implementation.

[0101] Step 403: In response to the interrupt to be processed being an inter-core interrupt, process the peripheral interrupt notified by the inter-core interrupt.

[0102] There are no restrictions on the specific processing implementation here; it can be implemented in a conventional manner.

[0103] Step 404: When the peripheral interrupt handling for the inter-core interrupt notification is completed, send an inter-core interrupt to the main processor to notify that the inter-core interrupt handling is complete.

[0104] In this embodiment, the master and slave processors disable hardware interrupts. When an inter-core interrupt bound to the slave processor is actively detected via software, the peripheral interrupt notified by the inter-core interrupt is processed, and the processing is completed via the inter-core interrupt notification. This embodiment avoids time-consuming steps such as hardware signal transmission and processor abnormal state switching in traditional interrupt paths. At the same time, the inter-core interrupt mechanism enables efficient task distribution among multiple processors, which can improve the response speed of interrupt processing.

[0105] In another example, interrupt controller monitoring from the processor side continues when any of the following conditions are met:

[0106] No pending interrupts were detected when monitoring the interrupt controller;

[0107] The detected pending interrupts are not inter-core interrupts;

[0108] Complete the processing of peripheral interrupts indicated by the inter-core interrupt.

[0109] The following provides a detailed process for implementing interrupt handling in the embodiments of this application, using specific application examples.

[0110] Taking a device with three processors as an example, namely processor 1, processor 2, and processor 3, processor 1 acts as the master processor, and processors 2 and 3 act as slave processors. Hardware interrupt response is disabled on all three processors, meaning they do not respond to hardware interrupt signals directly triggered by the interrupt controller. Instead, they actively monitor and process pending interrupts in the interrupt controller via software, binding peripheral interrupts triggered by peripheral devices to the master processor. That is, the interrupt controller sends all collected peripheral interrupts to the master processor via hardware, and when monitoring the interrupt controller, it only detects peripheral interrupts bound to the master processor. Specifically, all slave processors can be marked as idle, and then marked as non-idle when assigned to handle peripheral interrupts; alternatively, no status can be marked initially, and status can be marked after task allocation. This allows unmarked slave processors to be selected. For consistency, in this embodiment, processors 1 and 2 are marked as idle before interrupt processing.

[0111] See Figure 5 , Figure 5 This is a schematic diagram of the interrupt handling process in an embodiment of this application. The specific steps are as follows:

[0112] Step 501: Monitor the interrupt controller.

[0113] The monitoring of the interrupt controller here involves reading the interrupt status register of the interrupt controller to determine whether there are any pending interrupts.

[0114] Step 502: In response to the absence of any pending interruption detected, proceed to step 501.

[0115] If the monitoring determines that no interruption to be processed is detected, monitoring will continue to ensure real-time monitoring and timely processing.

[0116] Step 503: In response to the detection of a pending interrupt, determine whether the main processor is bound to the pending interrupt. If so, proceed to step 504; otherwise, proceed to step 509.

[0117] In this application embodiment, the processing logic for pending interrupts bound to the main processor and the slave processor is different. Therefore, it is necessary to distinguish whether the pending interrupt is bound to the main processor or the slave processor.

[0118] The main processor needs to determine the type of the interrupt to be processed: whether it is a peripheral interrupt, an inter-core interrupt, or another type of interrupt.

[0119] Step 504: If it is determined that the interrupt to be processed is neither a peripheral interrupt nor an inter-core interrupt, then step 501 is executed.

[0120] In this embodiment, if the main processor detects that the interrupt to be processed is neither an inter-core interrupt nor a peripheral interrupt, it will not process it and will continue to monitor. In other words, in this embodiment, interrupts that may be caused by abnormalities or other types of interrupts will not be paid attention to or processed. If it is another type of interrupt, it can be processed according to its relevant implementation.

[0121] Step 505: If it is determined that the interrupt to be processed is an inter-core interrupt, then notify the interrupt controller that the peripheral interrupt of the inter-core interrupt notification has been processed.

[0122] If it is an inter-core interrupt, it means that the processor has completed processing the peripheral interrupt notified by the main processor and returned a message indicating that the corresponding peripheral interrupt has been processed. Specifically, the processor can clear the pending status of the peripheral interrupt in the interrupt clear register of the interrupt controller.

[0123] Step 506: Control the main processor to mark the status of the slave processor handling the peripheral interrupt as idle, and execute step 501.

[0124] Marking the status of the slave processor handling the peripheral interrupt as idle indicates that the slave processor has completed its current task and is in an idle state, and can be selected as a candidate processor when selecting a slave processor in an idle state.

[0125] If the slave processor handling the peripheral interrupt is processor 2, then the state of slave processor 2 is marked as idle.

[0126] Step 507: If the interrupt to be processed is determined to be a peripheral interrupt, determine whether there is a slave processor in an idle state. If yes, proceed to step 508; otherwise, proceed to step 501.

[0127] When determining whether there is a slave processor in an idle state, determine the states of slave processor 1 and slave processor 2;

[0128] If there are multiple idle slave processors, i.e. both slave processor 1 and slave processor 2 are idle, then one of them is selected according to a preset rule. The preset rule can be to select one randomly, or to select one in order of serial number, etc. This application embodiment does not limit this.

[0129] If there is only one idle slave processor, then you can directly select that slave processor.

[0130] Step 508: Select a slave processor that is in an idle state, send an inter-core interrupt to the slave processor, and control the master processor to mark the target processor's state as non-idle. Execute step 501.

[0131] If there is no idle processor at present, the peripheral interrupt will not be processed for the time being, and monitoring will continue until an idle slave processor is found. If an inter-core interrupt is detected and a slave processor is released, the peripheral interrupt will then be processed.

[0132] Step 509: Determine whether the interrupt to be processed is an inter-core interrupt. If it is, proceed to step 510; otherwise, proceed to step 501.

[0133] In this embodiment, if the processor detects that the interrupt to be processed is not an inter-core interrupt, it will not process it and will continue to monitor. In other words, this embodiment does not pay attention to or process interrupts that may be caused by abnormalities or other types of interrupts. If it is another type of interrupt, it can be processed according to its relevant implementation.

[0134] Step 510: Control the processor to process the peripheral interrupt notification of the inter-core interrupt; when the peripheral interrupt processing of the inter-core interrupt notification is completed, send an inter-core interrupt to the main processor to notify the corresponding peripheral interrupt processing is complete. Execute step 501.

[0135] There are no restrictions on the specific implementation of the processor handling peripheral interrupts here; it can be implemented in a conventional manner.

[0136] This embodiment avoids time-consuming steps such as hardware signal transmission and processor abnormal state switching in traditional interrupt paths by masking hardware interrupts on the master and slave processors. Instead, it actively monitors interrupts via software. When a peripheral interrupt bound to the master processor is detected, an idle slave processor is selected, and the slave processor is notified to handle the peripheral interrupt via an inter-core interrupt. The master processor marks the slave processor's state as non-idle and monitors the interrupt processor again. When an inter-core interrupt bound to the master processor is detected, the corresponding peripheral interrupt handling is notified to the interrupt controller, and the master processor marks the slave processor's state as idle and continues monitoring the interrupt controller. When an inter-core interrupt bound to a slave processor is detected, the peripheral interrupt notified by the inter-core interrupt is handled, and upon completion, the corresponding peripheral interrupt handling is notified to the master processor via an inter-core interrupt, and monitoring of the interrupt controller continues. This embodiment achieves efficient task distribution among multiple processors through active software monitoring and notification of peripheral interrupts requiring handling or peripheral interrupt handling completion via inter-core interrupts, balancing low latency and multi-core scalability. Specifically:

[0137] Compared to traditional hardware interrupt handling, it significantly reduces interrupt handling response time;

[0138] High versatility: No need to modify the hardware design of peripherals or interrupt controllers; the code can be deployed on existing hardware platforms simply by running within the operating system.

[0139] Distribute peripheral interrupts to idle slave processors to avoid overloading a single slave processor.

[0140] In practical implementation, the interrupt controller commonly used in ARM architecture is called GIC. In the third-generation GIC, namely GICv3, a system register interface is included, which directly integrates some functions of the interrupt controller into the CPU. The CPU accesses the GIC more efficiently and faster. If the embodiment of this application is based on this interrupt controller, the pending interrupts of GIC access can be monitored.

[0141] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0142] Based on the same inventive concept, this application also provides an interrupt handling device. Applied to a device including a master processor and a slave processor, the device configures both the master processor and the slave processor to disable hardware interrupt responses; and configures peripheral interrupts to be sent to the master processor. See also... Figure 6 , Figure 6 This is a schematic diagram of the interrupt handling device in an embodiment of this application. The device includes:

[0143] Monitoring unit 601 is used to monitor the interrupt controller;

[0144] The judgment unit 602 is used to determine whether the interrupt to be processed is a peripheral interrupt or an inter-core interrupt in response to the detection of an interrupt to be processed and the interrupt to be processed is bound to the main processor.

[0145] The processing unit 603 is used to select a slave processor as the target processor if it is determined that the interrupt to be processed is a peripheral interrupt;

[0146] The sending unit 604 is used to send an inter-core interrupt to the target processor so that the target processor can process the peripheral interrupt notified by the inter-core interrupt; if it is determined that the interrupt to be processed is an inter-core interrupt, the interrupt controller is notified that the peripheral interrupt has been processed.

[0147] In another example,

[0148] The processing unit 603 is specifically used to select a slave processor that is currently in an idle state as the target processor when selecting a slave processor as the target processor; if there are multiple slave processors in an idle state, one of them is selected according to a preset rule.

[0149] In another example,

[0150] The sending unit 604 is further configured to, when sending an inter-core interrupt signal to the target processor, control the main processor to mark the target processor's state as non-idle; and when notifying the interrupt controller that the peripheral interrupt has been processed, control the main processor to mark the target processor's state as idle.

[0151] In another example,

[0152] The monitoring unit is further configured to continue monitoring the interrupt controller when any of the following conditions are met:

[0153] No pending interrupts were detected when monitoring the interrupt controller;

[0154] The detected interrupts to be processed are neither peripheral interrupts nor inter-core interrupts;

[0155] The detected interrupt to be processed is a peripheral interrupt, and there is currently no slave processor in an idle state;

[0156] The target processor is marked as non-idle.

[0157] The target processor is marked as idle.

[0158] In another example,

[0159] The judgment unit 602 is further configured to, in response to the detection of a pending interrupt and the pending interrupt being bound to a slave processor, determine whether the pending interrupt is an inter-core interrupt.

[0160] Processing unit 603 is further configured to process peripheral interrupts that notify of inter-core interrupts in response to the interrupt to be processed being an inter-core interrupt;

[0161] The sending unit 604 is further configured to send an inter-core interrupt to the main processor to notify the corresponding peripheral interrupt processing is complete when the peripheral interrupt processing of the inter-core interrupt notification is completed.

[0162] In another example,

[0163] The monitoring unit 601 is further configured to continue monitoring the interrupt controller when any of the following conditions are met:

[0164] No pending interrupts were detected when monitoring the interrupt controller;

[0165] The detected pending interrupts are not inter-core interrupts;

[0166] Complete the processing of peripheral interrupts indicated by the inter-core interrupt.

[0167] The units in the above embodiments can be integrated into one unit or deployed separately; they can be merged into one unit or further divided into multiple sub-units.

[0168] In another embodiment, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements an interrupt handling method when executing the program.

[0169] In another embodiment, a computer-readable storage medium is also provided, on which computer instructions are stored, which, when executed by a processor, implement an interrupt handling method.

[0170] Figure 7 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention. Figure 7 As shown, the electronic device may include: multiple processors 710, an interrupt controller 720, a memory 730, a communication bus 740, and a communication interface 750. Among the multiple processors 710, there is one master processor and multiple slave processors. Hardware interrupt responses are disabled on the multiple processors 710. The processors 710, communication interface 750, and memory 730 communicate with each other through the communication bus 740. The processors 710 can call logical instructions in the memory 730 to execute the following methods:

[0171] Configure the master and slave processors to disable hardware interrupt responses, and configure peripheral interrupts to be sent to the master processor.

[0172] Monitor the interrupt controller;

[0173] In response to the detection of a pending interrupt that is bound to the main processor, it is determined whether the pending interrupt is a peripheral interrupt or an inter-core interrupt.

[0174] If the interrupt to be processed is determined to be a peripheral interrupt, a slave processor is selected as the target processor, and an inter-core interrupt is sent to the target processor so that the target processor can process the peripheral interrupt notified by the inter-core interrupt;

[0175] If the interrupt to be processed is determined to be an inter-core interrupt, the interrupt controller is notified that the peripheral interrupt has been processed.

[0176] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0177] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0179] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments disclosed in this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in the order shown in different figures. For example, two blocks shown connectedly may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0180] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, without departing from the spirit and teachings of this application, the features described in the various embodiments of this application can be combined and / or combined in various ways, and all such combinations and / or combinations fall within the scope of this application.

[0181] This document uses specific embodiments to illustrate the principles and implementation methods of the present invention. The descriptions of these embodiments are merely illustrative of the method and core concepts of the present invention and are not intended to limit this application. Those skilled in the art can make changes to the specific implementation methods and application scope based on the ideas, spirit, and principles of the present invention. Any modifications, equivalent substitutions, or improvements made should be included within the scope of protection of this application.

Claims

1. An interrupt handling method, characterized in that, Applied to a device including a master processor and a slave processor, the master processor and the slave processor are configured to disable hardware interrupt response, peripheral interrupts are sent to the master processor, and the master processor and the slave processor are configured to operate in a manner that disables hardware interrupts; The interrupt status register of the interrupt controller is actively monitored via software; the method includes: Monitor the interrupt status register of the interrupt controller; In response to the detection of a pending interrupt that is bound to the main processor, it is determined whether the pending interrupt is a peripheral interrupt or an inter-core interrupt. If the interrupt to be processed is determined to be a peripheral interrupt, and there is an idle slave processor, then an idle slave processor is selected as the target processor, and an inter-core interrupt is sent to the target processor, so that the target processor can process the peripheral interrupt notified by the inter-core interrupt in software while maintaining the state of masking hardware interrupt processing; and the master processor is controlled to mark the state of the target processor as non-idle; wherein, the identifier of the inter-core interrupt sent has a corresponding relationship with the identifier of the peripheral interrupt; If the interrupt to be processed is determined to be a peripheral interrupt and there is no idle slave processor, then the peripheral interrupt will not be processed for the time being. If the interrupt to be processed is determined to be an inter-core interrupt, the interrupt controller is notified that the peripheral interrupt corresponding to the interrupt to be processed has been processed, and the main processor is controlled to mark the state of the target processor as idle.

2. The method according to claim 1, characterized in that, Selecting an idle slave processor as the target processor includes: Select a slave processor that is currently in an idle state as the target processor; If there are multiple idle slave processors, one of them will be selected according to preset rules.

3. The method according to claim 1, characterized in that, The method further includes continuing to monitor the interrupt controller when any of the following conditions are met: No pending interrupts were detected when monitoring the interrupt controller; The detected interrupts to be processed are neither peripheral interrupts nor inter-core interrupts; The detected interrupt to be processed is a peripheral interrupt, and there is currently no slave processor in an idle state; The target processor is marked as being in a non-idle state; The target processor is marked as being in an idle state.

4. The method according to claim 1, characterized in that, The method further includes: In response to the detection of a pending interrupt that is bound to the slave processor, it is determined whether the pending interrupt is an inter-core interrupt. In response to the interrupt to be processed being an inter-core interrupt, process the peripheral interrupt notified by the inter-core interrupt; When the peripheral interrupt handling of the inter-core interrupt notification is completed, an inter-core interrupt is sent to the main processor to notify the corresponding peripheral interrupt handling is complete.

5. The method according to claim 4, characterized in that, The method further includes continuing to monitor the interrupt controller when any of the following conditions are met: No pending interrupts were detected when monitoring the interrupt controller; The detected pending interrupts are not inter-core interrupts; The peripheral interrupt indicated by the inter-core interrupt has been processed.

6. An interrupt handling device, characterized in that, Applied to a device including a master processor and a slave processor, the master processor and the slave processor are configured to disable hardware interrupt response, peripheral interrupts are sent to the master processor, and the master processor and the slave processor are configured to operate in a mode that disables hardware interrupts; The device actively monitors the interrupt status register of the interrupt controller via software. The device includes: The monitoring unit is used to monitor the interrupt status register of the interrupt controller; The judgment unit is used to determine whether the interrupt to be processed is a peripheral interrupt or an inter-core interrupt in response to the detection of an interrupt to be processed and the interrupt to be processed is bound to the main processor. The processing unit is configured to, if it is determined that the interrupt to be processed is a peripheral interrupt and there is an idle slave processor, select an idle slave processor as the target processor; if it is determined that the interrupt to be processed is a peripheral interrupt and there is no idle slave processor, then temporarily not process the peripheral interrupt. The sending unit is configured to send an inter-core interrupt to the target processor, so that the target processor can process the peripheral interrupt notified by the inter-core interrupt in software while maintaining the state of masking hardware interrupt processing; and control the main processor to mark the state of the target processor as non-idle; wherein the identifier of the sent inter-core interrupt has a corresponding relationship with the identifier of the peripheral interrupt; if it is determined that the interrupt to be processed is an inter-core interrupt, the unit notifies the interrupt controller that the peripheral interrupt corresponding to the interrupt to be processed has been processed, and controls the main processor to mark the state of the target processor as idle.

7. The apparatus according to claim 6, characterized in that, The judgment unit is further configured to, in response to detecting a pending interrupt and the pending interrupt being bound to the slave processor, determine whether the pending interrupt is an inter-core interrupt; The processing unit is further configured to process the peripheral interrupt notification of the inter-core interrupt in response to the interrupt to be processed being an inter-core interrupt; The sending unit is further configured to send an inter-core interrupt to the main processor to notify the corresponding peripheral interrupt processing is complete when the peripheral interrupt processing of the inter-core interrupt notification is completed.

8. An electronic device, characterized in that, include: Multiple processors; An interrupt controller, which is connected to the plurality of processors via a system bus; A memory storing a computer program that, when executed by the processor, implements the method as described in any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images