Systems, methods, apparatus, and core particles for interrupt handling

Abstract

Disclosed are a system, method, device and core particle for interrupt handling, the system comprising: a manager, a repeater and an interrupter wherein the manager is used for sorting the response sequence of interrupt signals to send the sorted interrupt signals to the repeater; the repeater is used for filtering the sorted interrupt signals based on a filtering condition so as to send the filtered interrupt signals to a target core particle; and the interrupter is used for distributing the filtered interrupt signal received by the target core particle to the processor in the target core particle for processing according to the response sequence. Through the scheme of the invention, the interrupt distribution and processing flow among the core particles can be optimized by utilizing the characteristics of a multi-processor architecture.

Description

TECHNICAL FIELD

[0001] The present application relates generally to the technical field of integrated circuits. More particularly, the present application relates to a system, method, device and die for interrupt handling. BACKGROUND

[0002] In a multi-processor system, the complexity of interrupt handling is significantly increased, mainly because interrupt events need to be coordinated and managed among multiple processors. Interrupt synchronization, interrupt collision, and the challenge of real-time requirements are the three major problems that interrupt handling faces in such systems. The challenge of real-time requirements involves strict limitations on the system's response time and processing time for interrupts. In some high real-time application scenarios, such as aerospace, medical devices, etc., the system must be able to accurately respond to interrupts within a predetermined time, otherwise it may lead to task failure or serious consequences. However, traditional interrupt handling methods, especially in multi-processor systems, may have difficulty meeting these strict real-time requirements, because the synchronization and conflict resolution mechanisms in the interrupt handling process can introduce additional delays.

[0003] In traditional systems, the way hardware and software cooperatively handle interrupts usually relies on the coordination of the interrupt controller and the operating system kernel. The interrupt controller is responsible for receiving and managing interrupt requests from hardware devices, while the operating system kernel is responsible for scheduling and executing interrupt service programs. This approach works well in single-processor systems, but in multi-processor systems, due to the parallelism and interconnection complexity between processors, traditional interrupt handling methods have certain limitations. Existing technologies and previous solutions have alleviated these problems to some extent, but there are still some limitations in meeting the needs of modern complex systems. For example, existing technologies may not be able to fully utilize the parallel processing capabilities of multi-processor systems, or may not be efficient in implementing interrupt synchronization and resolving interrupt collisions. In addition, existing methods may also face challenges in ensuring system real-time performance, especially in scenarios where high-frequency interrupts or a large number of concurrent interrupt requests are processed.

[0004] Therefore, there is an urgent need to provide a system for interrupt handling between dies, in order to optimize interrupt allocation and processing flow by taking advantage of the characteristics of multi-processor architecture, and to develop new synchronization mechanisms and algorithms to improve the efficiency and real-time performance of interrupt handling, and to meet the needs of performance and maintainability. SUMMARY

[0005] To at least solve one or more of the technical problems as mentioned above, the present application proposes a system for interrupt handling between dies in the following aspects.

[0006] In a first aspect, the present application provides a system for corelet interrupt handling, comprising: a manager, a relay and an interrupter, wherein the manager is configured to order a response sequence of interrupt signals, and send the ordered interrupt signals to the relay; the relay is configured to filter the ordered interrupt signals based on a filter condition, and send the filtered interrupt signals to a target corelet; and the interrupter is configured to distribute the filtered interrupt signals received by the target corelet to a processor inside the target corelet according to the response sequence for processing.

[0007] In some embodiments, wherein the response sequence comprises a priority sequence, the manager is configured to order and send the interrupt signals in sequence according to the priority sequence.

[0008] In other embodiments, wherein the relay comprises a filter component and a routing component, wherein in filtering the ordered interrupt signals based on a filter condition, and sending the filtered interrupt signals to a target corelet: the filter component is configured to filter the interrupt signals based on the filter condition; and the routing component is configured to establish a mapping from the filtered interrupt signals to a location of a target corelet where an interrupt is processed, and send the interrupt signals to the target corelet where the interrupt is processed.

[0009] In yet other embodiments, wherein the filter condition comprises a predefined rule or configuration information, wherein the filtering comprises delaying or masking the interrupt signals.

[0010] In yet other embodiments, wherein the corelet comprises at least one communication interface configured to transmit the filtered interrupt signals between corelets.

[0011] In yet other embodiments, wherein the interrupter is distributed on all corelets, comprising a control component and a processing component, wherein in distributing the filtered interrupt signals received by the target corelet to a processor inside the target corelet according to the response sequence for processing: the control component selects, through a register of a first configuration interface of the corelet, an interrupt signal to be processed from the received filtered interrupt signals based on the response sequence; the control component selects, through a register of a second configuration interface of the corelet, a processor to process the interrupt signal to be processed; and the processing component controls the processor to run an interrupt program based on the response sequence to process the interrupt signal to be processed.

[0012] In yet other embodiments, wherein the control component comprises one or more processors inside the corelet, wherein the one or more processors are configured to perform the functions of the control component.

[0013] In yet other embodiments, the processing component includes one or more processors within the corelet, wherein the one or more processors are configured to perform the functions of the processing component.

[0014] In yet other embodiments, each control component is configured to respond to an interrupt signal based on a respective predetermined condition.

[0015] In a second aspect, the present application provides a method for interrupt processing among corelets, comprising: ordering a response sequence of interrupt signals; filtering the ordered interrupt signals based on a filtering condition; and distributing the filtered interrupt signals to a processor within a target corelet for processing according to the response sequence.

[0016] In a third aspect, the present application provides an apparatus for interrupt processing among corelets, comprising: a processor; a memory having stored thereon computer instructions for interrupt processing among corelets, which when executed by the processor, cause implementation of the method of the second aspect.

[0017] In a fourth aspect, the present application provides a corelet comprising the system of the first aspect.

[0018] With the system, method, apparatus and corelet for interrupt processing as provided above, the embodiments of the present application can optimize interrupt distribution and processing flow by taking advantage of the features of multi-processor architecture through management of interrupt signal response sequence. Further, in some embodiments, the efficiency and real-time performance of interrupt processing can be improved through predetermined filtering condition. In addition, in some embodiments, the distribution of interrupters can meet the requirements of performance and maintainability. BRIEF DESCRIPTION OF DRAWINGS

[0019] The above and other objects, features and advantages of the example embodiments of the present application will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0020] Figure 1 An exemplary flowchart of a method for interrupt processing among corelets according to an embodiment of the present application is shown;

[0021] Figure 2A An external centralized exemplary architecture diagram of a system for interrupt processing of corelets according to an embodiment of the present application is shown;

[0022] Figure 2B An external distributed exemplary architecture diagram of a system for interrupt processing of corelets according to an embodiment of the present application is shown;

[0023] Figure 2C An internal centralized exemplary architecture diagram of a system for interrupt processing of a corelet according to an embodiment of the present application is shown;

[0024] Figure 2D An internal distributed exemplary architecture diagram of a system for interrupt processing of a corelet according to an embodiment of the present application is shown;

[0025] Figure 3 A schematic block diagram of signal transmission between corelets according to an embodiment of the present application is shown;

[0026] Figure 4 An exemplary flow diagram of interrupt processing within a corelet according to an embodiment of the present application is shown;

[0027] Figure 5 A schematic block diagram of a control component within a corelet according to an embodiment of the present application is shown;

[0028] Figure 6 A schematic block diagram of an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0029] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of the present application.

[0030] It should be understood that the terms "comprise" and "include" used in the specification and claims of the present application indicate the presence of the described features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0031] It should also be understood that the terms used in the specification of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and claims of the present application, the singular forms "a", "an" and "the" are intended to include the plural forms unless the context clearly indicates otherwise. It should be further understood that the term "and / or" used in the specification and claims of the present application means any combination of one or more of the associated listed items and all possible combinations thereof, and includes these combinations.

[0032] As used in the specification and claims, the term “if’ can be interpreted as meaning “when,” or “upon,” or “in response to a determination,” or “in response to a detection” depending on the context. Similarly, the phrase “if it is determined” or “if [a described condition or event] is detected” can be interpreted as meaning “upon a determination” or “in response to a determination” or “upon detecting [a described condition or event]” or “in response to detecting [a described condition or event],” depending on the context.

[0033] In a multi-processor system, the traditional way of handling interrupts cooperatively by hardware and software mainly relies on the coordination between the interrupt controller and the operating system kernel. This mechanism was originally designed to handle tasks in a relatively simple single-processor environment, where the interrupt controller is responsible for receiving, managing, and distributing interrupt requests from hardware devices to the corresponding processors. However, with the growth of computing demands and the popularity of multi-processor systems, this traditional interrupt handling mechanism faces several major challenges.

[0034] Firstly, the traditional interrupt handling mechanism has the problem of low efficiency. In a multi-processor system, all interrupt requests are first centralized to an interrupt controller, and then the controller distributes the interrupts to a certain processor. This centralized interrupt management method can cause unbalanced load between processors, where some processors may be overused while others are idle. In addition, the centralized processing of interrupt requests can also cause processing delays, especially in high concurrency scenarios, the risk of the interrupt controller becoming a system bottleneck increases. Secondly, the traditional mechanism relies heavily on the operating system kernel when handling interrupts. Whenever an interrupt occurs, the operating system kernel needs to perform a series of interrupt service routines (ISRs), which include saving the current process state, selecting and executing the corresponding interrupt handling program, and restoring the process state. These operations increase the interrupt response time, especially in the case of handling a large number of interrupts, the overall performance of the system will be significantly affected.

[0035] To address the above problems, existing technologies have proposed some solutions, but the effects are not ideal. For example, some solutions try to distribute the pressure of interrupt handling by adding more interrupt controllers, or improve the interrupt handling process of the operating system kernel through software optimization. However, these methods either increase the hardware cost of the system or still cannot fundamentally solve the problems of low interrupt handling efficiency and uneven processor load.

[0036] The inventors have found that in order to effectively address the issue of interrupt handling in a multi-processor system, a new interrupt handling mechanism is needed that enables more intelligent interrupt distribution and handling directly at the hardware level. Specifically, one possible solution is to adopt a distributed interrupt controller architecture, where each processor is equipped with its own local interrupt controller. These local interrupt controllers can independently handle interrupt requests from hardware devices and intelligently decide whether to handle the interrupt themselves or forward it to other processors based on the current processor load and interrupt handling policy. Furthermore, under this architecture, more flexible interrupt priority management and fast inter-processor messaging can be supported by hardware, further improving the efficiency of interrupt handling and the overall performance of the system.

[0037] At the same time, this solution can also reduce the extent of operating system kernel intervention in interrupt handling through hardware acceleration. For example, by implementing part of the interrupt service routine in hardware, some basic interrupt handling tasks can be completed directly at the hardware level, thereby reducing the burden on the operating system kernel and shortening the interrupt response time. This hardware and software collaborative optimization of interrupt handling mechanism not only improves the efficiency of interrupt handling in a multi-processor system, but also enhances the scalability and flexibility of the system, better meeting the demand for high performance and high reliability in modern computing environments.

[0038] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the accompanying drawings.

[0039] Figure 1 An exemplary flowchart of a method 100 for interrupt handling between corelets is shown, which will be described below in conjunction with Figure 1 The method described in the present application will be further described.

[0040] It should be understood that the interrupt handling between corelets refers to a mechanism for coordinating and managing interrupt signals between processing units (i.e., corelets) in a multi-core or multi-processor computing environment. Interrupt handling is a way for a computer system to respond to external or internal events by pausing the current processing flow and handling higher priority tasks or events. When handling interrupts between corelets, technical details involved include but are not limited to the generation, transmission, reception, and handling mechanism of interrupt signals.

[0041] As Figure 1As shown, at step S101, the response sequence of interrupt signals is ordered. First, the generation of interrupt signals can originate from various situations, such as peripheral requests, software interrupt instructions, hardware faults, etc. These signals need to be effectively delivered to the corresponding processing units. In a multi-core or multi-processor system, this can involve complex signal routing mechanisms to ensure that interrupt signals are accurately delivered to the target core. Second, the reception and processing of interrupt signals require the target core to have corresponding hardware and software support. At the hardware level, the processor needs to have a dedicated interrupt control unit responsible for identifying and responding to external interrupt requests. At the software level, the operating system or specific interrupt handling programs need to be pre-configured so that when an interrupt signal is received, the context can be quickly switched and the interrupt service program can be executed.

[0042] Therefore, interrupt processing between cores needs to involve the management of interrupt priorities. In a multi-processor system, different interrupts can be assigned different priorities, and the system needs to decide the order of processing interrupts and whether to pause the current task on a core to respond to a higher priority interrupt based on these priorities.

[0043] At step S102, the ordered interrupt signals are filtered based on filtering conditions. This process refers to the mechanism of further screening and processing the preliminarily ordered interrupt signals in a multi-core or multi-processor system. This process aims to ensure that only interrupt signals that meet certain conditions can be delivered to processing units (i.e. cores) for processing, thereby improving the efficiency and response speed of the system, while reducing unnecessary resource consumption.

[0044] The ordered interrupt signals mean that the system has preliminarily organized and arranged the received interrupt signals according to certain rules (such as priority, timestamp, etc.). Such ordering is to ensure that more important or more urgent interrupts can be given priority. It should be noted that the filtering conditions can include one or more of the following factors, for example:

[0045] Interrupt source: The system may only allow interrupt signals from specific peripherals or internal modules to pass through, ignoring irrelevant or low-priority interrupt sources.

[0046] Interrupt type: According to the specific type of interrupt (such as hardware fault, software exception, peripheral request, etc.), the system can decide whether to process the interrupt.

[0047] Interrupt priority: Even after ordering, the system can further filter out only interrupt signals that meet or exceed a certain priority threshold.

[0048] System state: The current running state of the system (such as power management mode, security mode, etc.) can also affect the filtering logic of the interrupt signal.

[0049] Filtering mechanisms usually require both hardware support (such as programmable interrupt controllers) and software logic (such as the operating system's interrupt management module) to function. By setting filtering rules, the system can dynamically adjust its response strategy to interrupt signals, for example, responding only to the highest priority interrupt in low-power mode, or masking interrupt requests from certain peripherals during specific operations.

[0050] Additionally, the filtering process can also include mechanisms for merging or suppressing interrupt signals to handle situations where a large number of similar interrupt signals occur in a short period of time, preventing the processor from being frequently interrupted.

[0051] At step S103, the filtered interrupt signals are assigned to the target core's internal processor for processing according to the response order. In a multi-core or multi-processor system, mechanisms are needed to efficiently and orderly distribute and process the filtered and ordered interrupt signals. The core purpose of this mechanism is to ensure that each interrupt signal is responded to in a timely and correct manner, while optimizing the utilization of processor resources and maintaining the high performance of the system.

[0052] After the aforementioned steps, the system has filtered and ordered the interrupt signals to be processed according to the preset filtering conditions and priority rules. The next task is to reasonably distribute these interrupt signals to specific processing units (i.e. the target core's internal processor) for processing.

[0053] The response order is usually based on the priority of the interrupt signal, but other factors such as the characteristics of the interrupt source, the current load of the processor, the energy efficiency of the processor, etc. may also be considered. The system may use static or dynamic distribution strategies to maximize processing efficiency and system response speed. At the same time, in a multi-core or multi-processor system, the decision of which core and its internal processor to process a specific interrupt signal is a key decision. This decision needs to consider the load of the processor, the processing capacity, and the data and code related to the interrupt signal. For example, some interrupt processing may involve specific data structures or cache information, and selecting a processor that has recently processed related tasks can improve processing efficiency.

[0054] Once the interrupt signal is assigned to a specific processor, the processor needs to immediately execute the corresponding interrupt service routine (ISR). This requires the system to pre-configure the processing program corresponding to each interrupt signal and ensure that these programs can be quickly loaded and executed. After processing the interrupt, the system needs to perform necessary cleanup work, such as updating the interrupt state, clearing the interrupt flag, etc. At the same time, the processor needs to restore to the state before the interrupt occurred to continue executing the previous task.

[0055] Further, to improve the efficiency and response speed of the system, an interrupt load balancing technique can be used to dynamically assign interrupt handling tasks to different cores to avoid the situation where a single core is overloaded while others are idle. This technique is particularly suitable for scenarios where a large number of concurrent interrupt requests are processed, effectively avoiding performance bottlenecks caused by the overload of a single processor core.

[0056] In one embodiment, it is first necessary to identify and classify all interrupt sources and their generated interrupt requests in the system. This includes interrupts from peripherals such as network interface cards, disk drives, and USB devices. Each interrupt source is assigned a unique interrupt vector to identify different interrupt requests.

[0057] Next, during system initialization, an interrupt handling queue is established for each processing core. These queues are used to record the interrupt requests assigned to each core for processing. In the initial stage, the interrupt allocation strategy can be static, i.e., specific interrupt requests are allocated to specific processing cores according to preset rules. However, as the system runs, some cores may become overloaded due to processing high-load tasks, while others are relatively idle. To solve this problem, the interrupt load balancing technique introduces a dynamic interrupt reallocation mechanism. The core idea of this mechanism is to monitor the load of each processing core and dynamically adjust the allocation of interrupts based on the load to achieve load balancing.

[0058] Specifically, the system regularly collects load information for each core, including the number of interrupts currently being processed, the average time required to process interrupts, and the total processing capacity of the core. Based on this information, the system can calculate an optimal interrupt allocation scheme, i.e., transfer a portion of interrupts from overloaded cores to idle cores, thereby reducing the burden on overloaded cores and improving the utilization of idle cores. To achieve dynamic reallocation of interrupts, the system needs to have the ability to migrate interrupts. This usually involves modifying the configuration of the hardware interrupt controller to redirect the interrupt vector from one processing core to another. In some cases, the interrupt affinity problem needs to be considered to ensure that specific interrupt requests are allocated to the core that can most efficiently handle the request.

[0059] In addition, to avoid the performance overhead caused by frequent interrupt migration, the system also needs to set reasonable migration thresholds and migration frequencies. Only when the core load difference exceeds a certain threshold and a certain time interval has passed since the last interrupt migration, will the interrupt migration operation be performed.

[0060] Figure 2A , Figure 2B , Figure 2C and Figure 2DFour exemplary architecture diagrams of the system (210, 220, 230 and 240) for processing interrupts on corelets according to embodiments of the present application are shown, specifically a system for processing interrupts between corelets.

[0061] As shown in the figure, the system includes one or more of a manager 201, a repeater 202, and an interrupter 203. Before delving into the specific details of the system block diagram, it is important to understand that the system block diagram provides a conceptual perspective for illustrating how the different components of the system interact and cooperate to achieve a given function. This representation is exemplary, meaning that actual implementations can vary in many ways and are not limited by this block diagram. Next, this application will provide a more detailed explanation of the deployment methods of the manager and repeater, as well as the configuration of the processor.

[0062] First, regarding the deployment of managers and relays, they can be distributed (such as Figure 2B and Figure 2D ) or centralized (e.g. Figure 2A and Figure 2C ) architecture. In a distributed architecture, managers and repeaters are deployed in different locations in the system. Each device operates independently and coordinates work through network communication. This approach improves the flexibility and scalability of the system, allowing the system to better adapt to the needs of large-scale and complex environments. At the same time, a distributed architecture also enhances the system's fault tolerance, because even if some devices fail, the entire system can continue to operate. In a centralized architecture, all manager and repeater functions are concentrated in one or a few locations. This configuration simplifies management and maintenance, but may increase the risk of single points of failure and may encounter performance bottlenecks when processing large amounts of data or requests.

[0063] Secondly, for the configuration of the processor that implements the manager and repeater functions, it can be independent of the core grain (Figure A and Figure 2B ) hardware, or it can be powered by a processor inside the chip (such as Figure 2C and Figure 2D)Borne. When the processor is borne outside the core, it usually refers to a dedicated hardware device such as a server, a dedicated processing unit, etc. This configuration scheme can provide powerful computing power and flexible scalability, suitable for processing complex tasks and large amounts of data. In addition, independent hardware processors are also convenient for upgrading and replacing, which is conducive to maintaining the advancement and efficiency of the system. On the contrary, when the processor is borne by the processor inside the core, it means that the functions of the manager and the repeater are integrated into the design of the core. This integrated design can significantly reduce the physical size and power consumption of the system, making the system more compact and energy-efficient, especially suitable for application scenarios with strict requirements on space and energy consumption. However, this may limit the processing capacity and upgrade flexibility, as any changes to the processor may involve modifications to the core itself.

[0064] The manager 201 is used to sort the response order of the interrupt signals and send the sorted interrupt signals to the repeater. As mentioned earlier, an interrupt signal refers to a signal generated during the operation of computer hardware or software, which is used to inform the processor (CPU) to suspend the current task and process more urgent or specific tasks instead. These interrupt signals may come from various internal or external events, such as input / output requests, hardware failures, timer timeouts, etc. The manager 201 is a hardware or software component specially designed to handle these interrupt signals. Its core function is to effectively manage and schedule the received interrupt signals, ensuring that the system can respond to various interrupt requests in a reasonable and efficient manner.

[0065] The response order includes a priority order, and the manager is used to sort and send the interrupt signals according to the priority order. Here, a key concept is involved - priority order. Priority order is a sequence determined according to the urgency, importance or predefined rules of interrupt signals. Different interrupt signals are assigned different priorities to determine their order of processing.

[0066] The manager 201 sorts the received interrupt signals according to this priority order. This means that when multiple interrupt signals arrive simultaneously, the manager 201 will refer to the pre-set priority order to determine which signal should be processed first and which signal should be processed later, thereby achieving the purpose of sending the sorted interrupt signals to the repeater. The repeater is further responsible for delivering these sorted interrupt signals to the processor for execution of the corresponding interrupt service program.

[0067] In practical applications, this mechanism of prioritizing and sending interrupts in order can significantly improve the system's response efficiency and processing capacity for interrupts. By ensuring that higher priority tasks can be processed in a timely manner, the system can better meet the requirements of real-time and stability, especially in multitasking and real-time operating systems.

[0068] In addition, the manager 201 can also include some advanced functions, such as dynamically adjusting priorities, handling priority inversion problems, optimizing interrupt processing procedures, etc., to further improve the performance and reliability of the system.

[0069] The relay 202 is used to filter the sorted interrupt signals based on filtering conditions to send filtered interrupt signals to target cores. The relay 202 is a key hardware or software component designed to play a filtering and routing role in the interrupt signal processing procedure. This processing procedure aims to improve the efficiency and flexibility of the system's processing of interrupt signals, ensuring that only interrupt signals that meet certain conditions are passed to target cores (i.e. processor cores or processing units) for processing.

[0070] Among them, the relay includes a filtering component and a routing component, wherein the sorted interrupt signals are filtered based on filtering conditions to send filtered interrupt signals to target cores: the filtering component is used to filter interrupt signals based on the filtering conditions; and the routing component is used to establish a mapping from the filtered interrupt signals to the location of the target core where the interrupt processing is located, to send the interrupt signals to the target core where the interrupt processing is located.

[0071] The filtering conditions include predefined rules or configuration information, wherein the filtering includes delaying or masking interrupt signals.

[0072] Specifically, the responsibility of the filtering component is to screen the sorted interrupt signals according to the preset filtering conditions. These filtering conditions can be based on various factors, such as the type, source, priority of the interrupt, or any other available distinguishing information. The filtering conditions may include predefined rules or configuration information, so that system administrators or designers can customize which interrupt signals should be processed and which can be delayed or masked according to the needs of the actual application scenario. For example, some less important interrupt signals can be temporarily masked to ensure that more urgent tasks can be given priority; or when the system load is heavy, some low-priority interrupt signals can be selected to be delayed for processing.

[0073] The role of the routing component is to establish a path for the filtered interrupt signals from their current location to the target corelet. This involves determining which specific processor core or processing unit the interrupt signal should be sent to for processing. The routing component directs the filtered interrupt signals to the corresponding target corelet based on a mapping relationship. This mapping relationship can be dynamically adjusted based on factors such as the characteristics of the interrupt signals, the processing capabilities of the target corelets, the load balancing strategy of the system, and so on.

[0074] By combining the functions of the filtering component and the routing component, the relay 202 can effectively manage the flow of interrupt signals, ensuring that only those interrupt signals that meet certain conditions and priority requirements are delivered to the appropriate processing units. This not only reduces the occupation of system resources by irrelevant interrupt signals, but also improves the response speed of critical task processing and the overall performance of the system.

[0075] Further, after filtering, the transmission of interrupt signals between corelets is completed through the communication interface of the corelets (such as Figure 3 , the specific transmission process will be described in Figure 3 ). In a multi-core processor or multi-processor system, each processing unit (i.e., corelet) needs to effectively communicate to coordinate task execution and resource sharing. The transmission of interrupt signals is part of this communication mechanism, which allows one corelet to send an interrupt request to another corelet to prompt the receiving corelet to process certain specific events or tasks.

[0076] The interrupter 203 is used to distribute the filtered interrupt signals received by the target corelet to the processors inside the target corelet for processing according to the response order (as shown in Figure 4 , the specific corelet interrupt processing flow will be described in Figure 4 ). It should be noted that the interrupter is designed to ensure that interrupt signals can be correctly distributed and processed in a multi-core processor or multi-processing unit environment. After receiving the filtered interrupt signals filtered by the aforementioned relay 202, the interrupter 203 distributes these interrupt signals one by one to one or more processor cores inside the target corelet for processing according to the predetermined response order.

[0077] According to the determined response order, the interrupter 203 distributes the filtered interrupt signals to the processor cores inside the target corelet. This distribution process involves complex decision logic, including but not limited to evaluating the processing capacity, estimated processing time, and optimization goals (such as minimizing latency, balancing load, etc.) of each processor core. The interrupter 203 ensures that each interrupt signal can be delivered to the most suitable processor core for processing through internal control logic and routing mechanisms.

[0078] After the interrupt signal is assigned to a specific processor core, the interrupter 203 is also responsible for coordinating the scheduling of the processor cores. This can include waking up processor cores that are in low-power states, adjusting the running frequency of the cores, and reassigning interrupt handling tasks as necessary to cope with dynamically changing system states. The interrupter 203, through cooperation with the schedulers or management units inside the processor cores, ensures that the processing of interrupt signals is not only timely, but also efficient and energy-saving.

[0079] Figure 3 A schematic block diagram showing the signal transmission between the corelets of the embodiments of the present application is shown. Specifically, Figure 3 Further, a flow 300 of signal transmission between corelets through the communication interface is shown. First, it is necessary to understand Figure 3 The content shown and the design concept behind it. Figure 3 As an exemplary diagram, it aims to show a possible configuration scheme of the communication interface between corelets. In the design of a multi-core processor or a multi-processing unit system, the communication interface between corelets plays a crucial role, providing a physical or logical channel for data exchange and cooperation between corelets.

[0080] Figure 3 The number of corelet communication interfaces shown is exemplary and not limiting. In fact, each corelet can be equipped with 0, 1, 2, 3, or any integer number of communication interfaces. This flexibility allows system designers to choose the most suitable configuration according to specific application requirements and performance goals. For example, certain applications may not require high-frequency communication between corelets, so fewer communication interfaces can be chosen to optimize cost and power consumption; while for those applications that require high-speed, large-volume data exchange, more communication interfaces may be needed to meet performance requirements.

[0081] Further, the number of communication interfaces of each corelet can be different, which provides additional design flexibility and optimization space. Within the same chip or system, different corelets may have different tasks and functions, so their demand for communication interfaces will also be different. By configuring different numbers of communication interfaces for each corelet, the communication capability of each corelet can be adjusted more finely, thereby more effectively supporting its specific role and responsibility.

[0082] When determining the number of communication interfaces for each corelet, various factors need to be considered, including but not limited to the overall architecture of the system, data flow patterns, power consumption budget, cost constraints, and performance requirements of the target application. In addition, the type of communication interface (such as serial or parallel, point-to-point or bus, etc.), bandwidth, delay, etc. attributes also need to be considered to ensure that the selected configuration can meet the performance and efficiency goals at the system level.

[0083] Therefore, the corelet includes at least one communication interface for transmitting the filtered interrupt signal between corelets. Specifically, the transmission of interrupt signals between corelets is mainly completed through the communication interface of the corelet. These communication interfaces are key components in hardware design, which provide physical connections and data exchange channels between corelets. According to the specific system architecture and design requirements, these interfaces can be based on different communication protocols and technologies, such as direct memory access (DMA), serial bus protocols (such as I2C, SPI), parallel bus protocols, high-speed point-to-point connections (such as Intel's QuickPath Interconnect (QPI), AMD's Infinity Fabric), etc.

[0084] In the process of realizing the transmission of interrupt signals between corelets, the communication interface first needs to encode and package the outgoing interrupt signal to adapt to the transmission requirements of the underlying physical channel. This step includes converting the interrupt signal and its related information (such as priority, source corelet identifier, target corelet identifier, etc.) into a data format that conforms to a specific communication protocol. Subsequently, the encoded interrupt signal is sent to the target corelet through the physical channel. At the receiving end, the communication interface is responsible for decoding the received data, restoring the original interrupt signal, and submitting it to the interrupt manager or processor of the target corelet for processing.

[0085] In addition, in order to ensure reliable transmission and efficient processing of interrupt signals, the communication interface may also implement some advanced functions, such as error detection and correction, flow control, priority management, etc. These functions help improve the stability and responsiveness of the system, especially in high-load or complex communication scenarios.

[0086] Figure 4 An exemplary flowchart of interrupt processing 400 within a corelet of an embodiment of the present application is shown, the interrupter is designed to manage and distribute interrupt signals, which ensures that the system can respond to various external or internal events. In a system containing multiple corelets, the distributed architecture of the interrupter allows each corelet to independently process the interrupt signals it receives, thereby improving processing efficiency and system scalability.

[0087] The interrupter is distributed on all corelets, including a control component and a processing component, wherein in distributing the filtered interrupt signal received by the target corelet to the processor inside the target corelet for processing according to the response order: the control component selects an interrupt signal to be processed and selects a processor to process the interrupt signal to be processed; and the processing component controls the processor to run an interrupt program to process the interrupt signal to be processed based on the response order.

[0088] Specifically, the control component is responsible for monitoring and identifying incoming interrupt signals and selecting the interrupt signals to be processed according to a predetermined response order. This involves priority evaluation of the interrupt signals, current load and state monitoring of the processor cores, and considering factors such as the urgency of the task. The control component is also responsible for selecting the processor core that is most suitable for processing the selected interrupt signal. This selection is based on multiple criteria, including the capabilities of the processor, the current task load, the energy efficiency ratio, and the optimization of the processor for specific types of interrupts. The processing component is responsible for actually controlling the selected processor core to execute the interrupt handling program. This includes initializing the processing environment, loading the necessary interrupt service program, and monitoring the execution process of the interrupt handling to ensure that the interrupt service is completed as expected. The processing component enables each processor core to effectively process the interrupt signals assigned to it according to the response order, thereby ensuring the fast response of the system to interrupts.

[0089] In one embodiment, the processing component mentioned above can include one or more processors within the core particle, wherein the one or more processors are configured to perform the functions of the processing component.

[0090] Further, in the architecture of the interrupter, one or more processors within the core particle are configured to perform the functions of the processing component. This means that these processors are not only responsible for regular computing tasks, but also have the ability to process interrupt signals. By integrating interrupt processing functions at the processor level, the delay of interrupt processing can be reduced, and the response speed of the system can be improved. In addition, this configuration allows more flexible allocation of processing resources to adapt to different types and priorities of interrupt events.

[0091] Figure 5 A schematic block diagram of the control component 500 within the core particle of the embodiments of the present application is shown, which selects the interrupt signals to be processed from the received filtered interrupt signals based on the response order through the registers of the first configuration interface of the core particle; and selects the processor for processing the interrupt signals to be processed through the registers of the second configuration interface of the core particle.

[0092] Specifically, the core responsibility of the control component is to accurately select the interrupt signals to be processed from the received filtered interrupt signals based on the predetermined response order, and to determine the processor that is most suitable for processing these interrupt signals. To achieve this goal, the control component uses the configuration interface and registers within the core particle for efficient signal management and processor allocation.

[0093] The control component receives and analyzes the filtered interrupt signals through registers of the first configuration interface of the corelet. This configuration interface allows the control component to access one or more registers that store information about the interrupt signals, such as the type of interrupt, priority, source, etc. Based on this information and a pre-set response order (possibly taking into account factors such as priority, first-come-first-serve, etc.), the control component executes a complex decision algorithm to select which interrupt signals will be marked as "pending". This process involves the evaluation of various interrupt signal attributes to ensure that the system responds to the most urgent or important events.

[0094] Once the pending interrupt signals are determined, the control component then selects the appropriate processors to handle these interrupts through registers of the second configuration interface of the corelet. The second configuration interface provides an interface for the control component to the corelet's processor allocation strategy, allowing the control component to dynamically select processors based on current processor load, specific processor's ability to handle certain types of interrupts, and other runtime conditions (such as energy efficiency). Through this interface, the control component can modify the values of designated registers, assigning specific processor cores to execute the interrupt service routines.

[0095] In one embodiment, the aforementioned control component can include one or more processors within the corelet, where the one or more processors are configured to perform the functions of the control component. This means that the processors of the control component not only perform regular computing tasks, but also take responsibility for the decision-making process of interrupt management and processor allocation. This design makes interrupt handling more flexible and efficient, as it allows real-time adjustments in processor resource allocation and interrupt signal management.

[0096] In another embodiment, each of the aforementioned control components responds to target interrupt signals based on respective pre-set conditions. These pre-set conditions can include the priority of the interrupt, the impact of specific types of interrupts on system operation, and the current state of the processors, etc. By refining these conditions, the system is able to handle interrupts in a more intelligent and efficient manner, ensuring that critical tasks are prioritized while optimizing the use of processor resources.

[0097] Figure 6 A schematic block diagram of an electronic device according to an embodiment of the present application is shown. As shown, the electronic device 600 can include a processor 601 and a memory 602. The memory 602 stores computer instructions for interrupt handling, which when executed by the processor 601, cause the electronic device 600 to perform the functions described in the foregoing in connection with Figure 6 the embodiments of the present application. Figures 1-5 The electronic device 600 can be any device capable of running computer programs, such as a smartphone, a tablet computer, a laptop computer, a desktop computer, a server, etc.

[0098] In some embodiments, various aspects of the present disclosure may also be implemented in the form of a program product comprising program code that, when executed by a processor, causes the processor to perform the method described above. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0099] Although multiple embodiments of the present application have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Those skilled in the art can conceive of many changes, modifications, and alternatives without departing from the thought and spirit of the present application. It should be understood that in the process of practicing the present application, various alternatives to the embodiments of the present application described herein can be adopted. The accompanying claims are intended to define the scope of protection of the present application and therefore cover equivalents or alternatives within the scope of these claims.

Claims

1. A system for handling inter-core particle interruptions, characterized by comprising a manager, a relay and an interrupter, wherein, the manager is configured to sort a response order of interrupt signals, and send the sorted interrupt signals to the relay; the relay is configured to filter the sorted interrupt signals based on filter conditions, and send the filtered interrupt signals to target cores; and the interrupter is configured to distribute the filtered interrupt signals received by the target cores to processors inside the target cores according to the response order.

2. The system of claim 1, wherein, wherein the response order comprises a priority order, and the manager is configured to sort and send the interrupt signals in order according to the priority order.

3. The system of claim 1, wherein, wherein the relay comprises a filter component and a routing component, wherein in filtering the sorted interrupt signals based on filter conditions, and sending the filtered interrupt signals to target cores: the filter component is configured to filter interrupt signals based on the filter conditions; and the routing component is configured to establish a mapping from the filtered interrupt signals to locations of target cores where interrupt processing is performed, and send the interrupt signals to the target cores where the interrupt processing is performed.

4. The system of claim 3, wherein, wherein the filter conditions comprise pre-defined rules or configuration information, and wherein the filtering comprises delaying or masking interrupt signals.

5. The system of claim 4, wherein, wherein the cores comprise at least one communication interface configured to transmit the filtered interrupt signals between cores.

6. The system of claim 1, wherein, wherein the interrupter is distributed on all cores, comprising a control component and a processing component, wherein in distributing the filtered interrupt signals received by the target cores to processors inside the target cores according to the response order: the control component selects, based on the response order, interrupt signals to be processed from the received filtered interrupt signals via registers of a first configuration interface of the core; the control component selects, via registers of a second configuration interface of the core, processors to process the interrupt signals to be processed; and the processing component controls the processors to run interrupt programs based on the response order to process the interrupt signals to be processed. wherein the control component comprises one or more processors inside the core, and wherein the one or more processors are configured to perform the functions of the control component.

7. The system of claim 6, wherein, wherein the processing component comprises one or more processors inside the core, and wherein the one or more processors are configured to perform the functions of the processing component.

8. The system of claim 7, wherein, wherein each control component is configured to respond to target interrupt signals based on respective pre-set conditions.

9. The system of claim 7, wherein, comprising:

10. A method of performing an interrupt process between corelets, characterized by, sorting a response order of interrupt signals; filtering the sorted interrupt signals based on filter conditions; and distributing the filtered interrupt signals to processors inside target cores according to the response order. comprising: a processor; 11. An apparatus for handling an interruption between corelets, characterized by, a memory having stored thereon computer instructions for interrupt processing between cores, which when executed by the processor, cause implementation of the method according to claim 10. the system of any one of claims 1-9. the system of any one of claims 1-9.

12. A core particle, characterized in that, ​

Images