WO2019169582A1

WO2019169582A1 - Method and device for processing interrupt

Info

Publication number: WO2019169582A1
Application number: PCT/CN2018/078331
Authority: WO
Inventors: 陈奔
Original assignee: 华为技术有限公司
Priority date: 2018-03-07
Filing date: 2018-03-07
Publication date: 2019-09-12
Also published as: CN109791503A

Abstract

Provided are a method and a device (700) for processing an interrupt. The method comprises: a central processing unit (CPU) (130) receiving an interrupt request (410); the CPU (130) obtaining a system event triggering the interrupt request (420); and the CPU (130) instructing a coprocessing unit (120) to process the system event (430). The method and the device (700) directly send interrupt requests sent by a part of interrupt sources (110) in a computing device (100) to the coprocessing unit (120), such that the coprocessing unit (120) processes a system event corresponding to the interrupt requests; compared to a solution in which the CPU (130) processes all interrupt requests in the computing device (100), the scenario is avoided in which the CPU (130) cannot run an application for a long time because the CPU (130) is processing a system event, improving overall performance of the computing device (100).

Description

Method and apparatus for handling interruptions

Technical field

The present application relates to the field of computers and, more particularly, to methods and apparatus for handling interrupts.

Background technique

A computer, a server, or other computing capable device may be collectively referred to as a computing device, and the computing device may include a hardware system and a software system, wherein the hardware system includes a hardware device of the computer, such as a memory, a power source, etc.; the software system includes an operating system (Operating System, OS).

When there are system events in the computing device that need to be processed, for example, the hardware in the hardware system needs to send the specific running state of the hardware to the software system, or the software system needs to run a specific program to help the hardware enter the normal working state, the hardware can pass The interrupt mechanism interacts with the software system. That is, the hardware device in the hardware system can send an interrupt request to the software system, request the software system to interrupt the currently running program, run the interrupt handler, and process the system event.

This way of handling system events occupies the computing resources of the central processing unit, so that the central processing unit cannot run the interrupted application during the processing of system events, reducing the overall performance of the computing device.

Summary of the invention

The present application provides a method and apparatus for handling interrupts that are beneficial for improving the overall performance of a computing device.

In a first aspect, a method for processing an interrupt is provided, comprising: a central processing unit (CPU) receiving an interrupt request; the CPU acquiring a system event that triggers the interrupt request; and the CPU instructing a coprocessing unit to process System events.

Specifically, the interrupt request is used to request the CPU to interrupt the currently running program and enter the interrupt processing flow.

The system event can be a type of business event generated by system activity and including system data. System events can include resource state changes, threshold violations, or abnormal system states and behaviors.

In the embodiment of the present application, the CPU sends a system event for processing the interrupt request to the co-processing unit, and the co-processing unit replaces the CPU to process the system event corresponding to the interrupt request. Compared with the scheme of processing all system events by the CPU, the CPU is prevented from running the interrupted application for a long time due to processing system events, which is beneficial to improve the overall performance of the computing device.

With reference to the first aspect, in a possible implementation, when the target processing unit is the co-processing unit, before the CPU instructs the co-processing unit to process the system event, the method further includes: the central processing unit may The pre-stored interrupt request is published, and the target processing unit that selects a processing system event is determined, and the interrupted sub-publishing records a mapping relationship between the plurality of types of interrupt requests and the plurality of processing units, wherein the plurality of processing units include the central processing unit And the co-processing unit.

The interrupt sub-publishing can record the correspondence between the interrupt request type and the routing information, and the routing information is used to route the interrupt request to the target processing unit. After the interrupt source is published by checking the interrupt, and determining the routing information corresponding to the interrupt request, the routing information can be determined according to the The subsequent routing information encapsulates the interrupt request such that the interrupt request can be routed to the target processing unit based on the determined routing information.

It should be noted that the routing information may include a port number of a port through which the interrupt request is transmitted, or a routing address of the target processing unit.

In the embodiment of the present application, the central processing unit allocates different types of interrupts to different target processing unit processing by interrupting the sub-publishing, that is, assigning different types of interrupts according to the processing capabilities of different target processing units, and processing different system events. It is beneficial to improve the efficiency of the target processing unit processing system events.

Alternatively, the central processing unit may instruct different co-processing units to handle different types of system events.

With reference to the first aspect, in a possible implementation manner, the CPU acquires current load information of the CPU, and the CPU indicates, when the load of the CPU indicated by the current load information is higher than a target threshold. The coprocessing unit processes the system event.

In the embodiment of the present application, when the load indicated by the current load information of the CPU is higher than the target threshold, the CPU instructs the coprocessing unit to process the system event, thereby avoiding the efficiency of processing the system event caused by the coprocessing unit processing the system event. It is beneficial to balance the performance of computing devices and the efficiency of handling system events. At the same time, the co-processing unit shares the extra load caused by system events when the CPU is running at high load.

With reference to the first aspect, in a possible implementation manner, when the type of the system event is a target type, the CPU instructs the co-processing unit to process the system event, and the target type indicates the co-processing The unit processes system events having the target type.

The target type instructs the co-processing unit to process a system event having the target type. At the same time, the co-processing unit has the ability to handle system events of the target type.

When a system event is not a system event of the target type, a system event of a non-target type can be directly processed by the CPU.

One possible design, the co-processing unit does not have the ability to handle system events of a non-target type. There are many reasons why the co-processing unit does not have a system event for processing a non-target type. For example, the program configured to process the system event in the computing device can only be processed by the CPU, or the co-processing unit cannot obtain the system corresponding to the interrupt request. The specific content of the event, the interrupt handler could not be run to handle the system event. This embodiment of the present application does not specifically limit this.

With reference to the first aspect, in a possible implementation manner, the system event includes multiple sub-events, and the CPU instructs the co-processing unit to process the system event, including: the CPU instructs the co-processing unit to process At least one of the plurality of sub-events.

Specifically, the CPU instructs the coprocessing unit to process at least one of the plurality of sub-events, which may be that the co-processing unit processes all sub-events of the plurality of sub-events (ie, the co-processing unit processes the system event) Or, it may be that the co-processing unit processes some of the sub-events of the plurality of sub-events.

In the embodiment of the present application, the at least one sub-event is processed by the co-processing unit, and the sub-event other than the at least one sub-event of the plurality of sub-events is processed by the CPU, that is, the co-processing unit and the CPU co-process the system event, It helps to reduce the time for the CPU to handle system events and improve the overall performance of the computing device.

Optionally, the sub-event other than the at least one sub-event of the plurality of sub-events, that is, the sub-event that is not indicated to the co-processing unit among the plurality of sub-events, may be processed by the central processing unit.

With reference to the first aspect, in a possible implementation manner, the CPU acquires current load information of the CPU; when the CPU loads the CPU indicated by the current load information that is higher than a target threshold, the CPU At least one of the plurality of sub-events included in the system event is selected. The CPU instructs the coprocessing unit to process the selected sub-event.

In the embodiment of the present application, when the load indicated by the current load information of the CPU is higher than the target threshold, the CPU instructs the co-processing unit to process a part of the sub-event in the system event, thereby avoiding processing by the co-processing unit to process the system event. The efficiency of the overall system event is degraded, which is beneficial to the performance of the computing device and the efficiency of handling system events.

With reference to the first aspect, in a possible implementation manner, the CPU selects a sub-event that matches a target type from the plurality of sub-events, and the sub-event that matches the target type is the at least one sub-event, The target type instructs the co-processing unit to process a sub-event having the target type. The CPU instructs the coprocessing unit to process the selected sub-event.

It should be noted that the target type indicates that the coprocessing unit processes the sub-event having the target type. At the same time, the co-processing unit has the ability to process sub-events of the target type.

In conjunction with the first aspect, in a possible implementation manner, the method further includes: the CPU processing a sub-event of the plurality of sub-events other than the at least one sub-event.

That is to say, among the plurality of sub-events, sub-events of the non-target type can be processed by the CPU. In other words, when multiple sub-events include sub-events of the target type and sub-events of the non-target type, multiple sub-events can be co-processed by the CPU and the co-processing unit.

With reference to the first aspect, in a possible implementation, the CPU enters an interrupt according to the interrupt request; and the CPU processes a sub-event other than the at least one sub-event in the plurality of sub-events , exit the interrupt.

In the embodiment of the present application, when the CPU processes a sub-event other than the at least one sub-event among the plurality of sub-events, the interrupt may be exited, and the previously interrupted application is processed, which requires more processing than the central processing unit. For the scenario of all sub-events in a sub-event, it is beneficial to reduce the time that the central processing unit handles system events.

In combination with the first aspect, in a possible implementation manner, when the CPU directly forwards the interrupt request to the coprocessing unit, the CPU may not acquire the system event that triggers the interrupt request.

Optionally, before the CPU instructs the coprocessing unit to process the system event, the method further includes: the CPU querying an interrupt forwarding table, where the interrupt forwarding table records multiple types of interrupt requests and multiple coprocessing a mapping relationship of cells; the CPU determines the coprocessing unit corresponding to the interrupt request.

In the embodiment of the present application, the CPU allocates different types of interrupt requests to different target processing unit processing by interrupting the forwarding table, that is, assigning different types of system events based on processing capabilities of different target processing units, which is beneficial to improve the target. The processing unit handles the efficiency of system events.

A second aspect provides a method for processing an interrupt, comprising: acquiring, by a coprocessing unit, a system event that is instructed by the coprocessing unit, the system event indicated by the CPU being acquired by the CPU when receiving an interrupt request A system event that triggers the interrupt request; the co-processing unit processes the acquired system event.

The system event corresponding to the interrupt request is processed by the coprocessor unit instead of the CPU. Compared with the scheme of processing all system events by the CPU, the CPU is prevented from running the interrupted application for a long time due to processing system events, which is beneficial to improve the overall performance of the computing device.

With reference to the second aspect, in a possible implementation manner, the method further includes: the coprocessing unit receives an interrupt request sent by an interrupt source; and the coprocessing unit acquires a system event that triggers the interrupt request.

It should be noted that a communication mechanism for transmitting an interrupt request can be established between the interrupt source and the coprocessing unit, so that the interrupt source can directly send the interrupt request to the coprocessing unit.

With reference to the second aspect, in a possible implementation manner, the method further includes: the coprocessing unit receives an interrupt request forwarded by a CPU, where the interrupt request is sent to the CPU as an interrupt source; Get the system event that triggered the interrupt request.

In the embodiment of the present application, the hardware connection between the interrupt source and the co-processing unit may be improved, and the interrupt request may be forwarded by the CPU to the co-processing unit, so that the co-processing unit processes the system event that triggers the interrupt request.

With reference to the second aspect, in a possible implementation manner, the method further includes: the coprocessing unit enters an interrupt according to the interrupt request; and the coprocessing unit exits the system event when the system event is processed Interrupted.

A third aspect provides a method for processing an interrupt, including: an interrupt source generating an interrupt request; the interrupt source query interrupt distribution policy determining a target processing unit corresponding to the interrupt request, where the interrupt distribution policy includes: a first type of The interrupt request is processed by the central processing unit CPU, and the second type of interrupt request is processed by the co-processing unit; the interrupt source sends the interrupt request to the target processing unit corresponding to the interrupt request.

The target processing unit includes the co-processing unit or the central processing unit.

The target processing unit corresponding to the interrupt request may be understood to be that the target processing unit receives the interrupt request, and further, the system event that triggers the interrupt request may be processed by the target processing unit.

In the embodiment of the present application, for the same interrupt source, by interrupting the distribution policy, different types of interrupt requests of the interrupt source are allocated to different target processing unit processes, that is, different allocations are based on processing capabilities of different target processing units. Types of interrupts help to improve the efficiency of the target processing unit in handling system events.

With reference to the third aspect, in a possible implementation manner, the interrupt distribution policy includes interrupting a sub-publishing, and the interrupt sub-publishing records a mapping relationship between multiple types of interrupt requests and a plurality of processing units, the multiple processing The unit includes a CPU and a coprocessing unit.

In combination with the third aspect, in a possible implementation manner, the interrupt sub-publishing may record a correspondence between an interrupt request type and routing information, the routing information is used to route the interrupt request to the target processing unit, and the interrupt source queries the interrupt. After the routing information corresponding to the interrupt request is determined, the interrupt request may be encapsulated according to the determined routing information, so that the interrupt request may be routed to the target processing unit based on the determined routing information.

In the embodiment of the present application, for the same interrupt source, different types of interrupts of the interrupt source are allocated to different target processing unit processing by interrupting the sub-publishing, that is, different types are allocated based on the processing capabilities of different target processing units. The interruption helps to improve the efficiency of the target processing unit handling system events.

In conjunction with the third aspect, in a possible implementation, the second type of interrupt request is a fault type interrupt request.

In a fourth aspect, a method for processing an interrupt by a computing device is provided, the computing device comprising a CPU, a co-processing unit, and an interrupt source, wherein the CPU, the co-processing unit, and the interrupt source cooperate with each other to perform the methods in the above aspects.

In a fifth aspect, an apparatus for processing an interrupt is provided, the apparatus comprising means for performing each of the various methods described above.

In a sixth aspect, a computing device is provided, the computing device comprising a CPU implementing the above method. The functions of the CPU can be implemented by hardware or by executing corresponding software through hardware. The hardware or software implements one or more units corresponding to the functions described above.

The computing device can also include a co-processing unit that implements the above method. The functions of the co-processing unit can be implemented by hardware or by corresponding software implementation by hardware. The hardware or software implements one or more units corresponding to the functions described above.

In a seventh aspect, a computing device is provided, the computing device having an interrupt source implementing the above method. The function of the interrupt source can be implemented by hardware or by executing the corresponding software through hardware. The hardware or software implements one or more units corresponding to the functions described above.

In an eighth aspect, a CPU is provided, the CPU including an input/output interface, a control unit, and a register. The control component is configured to decode the instruction and issue a control signal for each operation to be performed for each instruction, the register is used to store the register operand and the operation result temporarily stored during the execution of the instruction, and the input and output interface is used for receiving the input. Data and information, output data operation results and other data.

In a ninth aspect, a coprocessing unit is provided, the coprocessing unit including an input/output interface, a processing unit, and a register. The control component is configured to decode the instruction and issue a control signal for each operation to be performed for each instruction, the register is used to store the register operand and the operation result temporarily stored during the execution of the instruction, and the input and output interface is used for receiving the input. Data and information, output data operation results and other data.

In a tenth aspect, an interrupt source is provided, the interrupt source comprising a controller, an input/output interface, and a memory. The controller is used to control the input/output interface to receive input data and information, and output data such as operation results. The memory is for storing program code, the controller is for calling and running the program code from the memory such that the interrupt source performs the operation of the interrupt source in the above method.

In an eleventh aspect, a computing device is provided, including a CPU, a coprocessing unit, and an interrupt source, wherein the CPU is configured to perform operations of the CPU in the foregoing method, and the coprocessing unit is configured to perform operations of the coprocessing unit in the foregoing method, The interrupt source is used to perform the operation of the interrupt source in the above method.

In a twelfth aspect, a computer program product is provided, the computer program product comprising program code. When the program code is run on a computing device, the computing device is caused to perform the methods of the various aspects described above.

In a thirteenth aspect, a computer readable medium is provided, the computer readable medium storing program code. When the program code is run on a computing device, the computing device is caused to perform the methods of the various aspects described above.

In a fourteenth aspect, a chip system is provided, the chip system being disposed in a CPU for implementing functions involved in the above aspects, for example, generating, receiving, transmitting, or processing data involved in the above method and/or Or information. In one possible design, the chip system further includes a memory for storing program instructions and data necessary for the chip system. The chip system can be composed of chips, and can also include chips and other discrete devices.

In a fifteenth aspect, a chip system is provided, the chip system being disposed in a coprocessing unit for supporting a coprocessing unit to implement functions involved in the above aspects, for example, generating, receiving, transmitting, or processing the above method Data and/or information involved. In one possible design, the chip system further includes a memory for storing program instructions and data necessary for the chip system. The chip system can be composed of chips, and can also include chips and other discrete devices.

In a sixteenth aspect, a chip system is provided, the chip system being disposed in an interrupt source for supporting an interrupt source to implement the functions involved in the above aspects, for example, generating, receiving, transmitting or processing the method involved in the above method Data and / or information. In one possible design, the chip system further includes a memory for storing program instructions and data necessary for the chip system. The chip system can be composed of chips, and can also include chips and other discrete devices.

DRAWINGS

FIG. 1 is a schematic block diagram of a computing device to which an embodiment of the present application is applied.

2 is a schematic flow diagram of a conventional method of handling system events.

FIG. 3 is a schematic flowchart of a method for processing an interrupt according to an embodiment of the present application.

FIG. 4 is a schematic flowchart of a method for processing an interrupt according to another embodiment of the present application.

FIG. 5 is a schematic flowchart of a method for processing an interrupt according to another embodiment of the present application.

FIG. 6 is a schematic flowchart of a method for processing an interrupt according to another embodiment of the present application.

FIG. 7 is a schematic block diagram of an apparatus for processing an interrupt according to an embodiment of the present application.

FIG. 8 is a schematic block diagram of a central processing unit of an embodiment of the present application.

FIG. 9 is a schematic block diagram of an apparatus for processing an interrupt according to an embodiment of the present application.

FIG. 10 is a schematic block diagram of a co-processing unit of an embodiment of the present application.

FIG. 11 is a schematic block diagram of an apparatus for processing an interrupt according to an embodiment of the present application.

FIG. 12 is a schematic block diagram of an interrupt source of an embodiment of the present application.

Detailed ways

The technical solutions in the present application will be described below with reference to the accompanying drawings.

FIG. 1 is a schematic block diagram of a computing device to which an embodiment of the present application is applied. The computing device 100 shown in FIG. 1 includes a central processing unit (CPU) 110, a co-processing unit 120, an interrupt source 130, and a memory 140. The internal connection between the central processing unit 110, the coprocessing unit 120, the interrupt source 130, and the memory 140 can be connected, for example, via a bus.

It should be understood that the computing device 100 can be a device that provides computing services, such as a server. The computing device 100 can also be an electronic computer for high speed computing, such as a computer. The specific embodiments of the computing device are not limited in this embodiment.

It should be understood that the computing device 100 shown in FIG. 1 only lists the components related to the embodiment of the present application. The computing device 100 shown in FIG. 1 may further include other components, such as a network card, a hard disk, etc. This is not specifically limited.

The central processing unit 110 runs an operating system of the computing device 100 and runs programs, such as applications, in the operating system.

In particular, central processing unit 110 can be a large scale integrated circuit that acts as the computing core and control core of computing device 100.

It should be noted that the central processing unit 110 can be a chip or a chip system. If the central processing unit 110 is a chip system, the chip system may include a plurality of chips.

The co-processing unit 120 can run a portion of the programs in the computing device 100.

Optionally, the co-processing unit 120 may be a co-processor that completes the inefficient operation task of the central processing unit 110; for example, the co-processing unit may be a graphics processing unit (Graphics Processing Unit, GPU) or Neural-network Processing Unit (NPU).

Optionally, the coprocessing unit 120 may be an out-of-band processing unit in the computing device 100, for example, a processing unit in a service processor (SP), a system on a chip (Soc) in a computing device. Wait.

The coprocessing unit 120 can be implemented by a chip. For example, co-processing unit 120 can be a chip or can be a chip system. If the coprocessing unit 120 is a chip system, the chip system may include a plurality of chips.

The interrupt source 130 is capable of initiating an interrupt request in the computing device 100. The interrupt source 130 can be a hardware device in the computing device 100, such as an I/O device, a data channel, a real time clock, or a source of user faults, and the like.

Optionally, the specific embodiment of the interrupt request may be an interrupt signal, or interrupt information, and the like.

The memory 140 provides instructions and data to a central processing unit and/or a co-processing unit. The memory 140 may include a read only memory or a random access memory.

The conventional method of computing device 100 processing system events is described below in conjunction with FIG. 2 based on the architectural diagram of computing device 100 shown in FIG. 2 is a schematic flow diagram of a conventional method of handling system events. The method shown in FIG. 2 includes steps 210 to 220.

210. The interrupt source of the computing device sends an interrupt request to the central processing unit.

The interrupt request is used to request the central processing unit to interrupt the currently running application and enter the interrupt processing flow.

220. The central processing unit interrupts the currently running program and processes the system event.

Specifically, after entering the interrupt processing flow, the central processing unit determines a system event that triggers the interrupt request, and processes the system event.

The system event can be a type of business event generated by system activity and including system data. System events can include resource state changes, threshold violations, or abnormal system states and behaviors. For example, the system event may refer to the current state of the interrupt source that needs to be sent to the software system in the computing device, or the interrupt source needs to run a particular program through the software system in the computing device to cause the interrupt source to enter a working state.

In the method shown in FIG. 2, all interrupt sources in the computing device send an interrupt request to the central processing unit, so that the central processing unit enters the interrupt processing flow and processes the system event corresponding to the interrupt request. The way in which the interrupt request is processed occupies the computing resources of the central processing unit, so that the central processing unit cannot run the interrupted application or OS during the processing of the system event, causing the application or the OS to be unable to provide services for a long time, thereby reducing the computing device. Overall performance.

For example, when a system event is dynamically configured for a hardware system through a software system, the CPU takes longer to process system events. The CPU will not be able to run the interrupted application for a long period of time, reducing the overall performance of the computing device.

As another example, a system event indication is configured for hardware in a computing device, and the interrupt triggered by the system event is typically a system management interrupt (SMI). The system event is a system event processed by a basic input/output system (BIOS). During the process of processing the system event by the BIOS, the BIOS will grab the control of the OS on the CPU. When the BIOS takes a long time for the CPU, the OS cannot be controlled for a long time, which may cause service interruption or software system jam. In order to avoid the business interruption of the computing device or the software system is stuck, only the way of alternately controlling the CPU between the BIOS and the OS can be adopted. In a period of time, the BIOS takes over the CPU to handle system events, and in another period, the OS takes over the CPU to run the application. This way in which the BIOS and the OS alternately control the CPU, the computing device needs to constantly switch between the BIOS and the OS to control the CPU, and also reduces the overall performance of the computing device.

The present application provides a method for processing an interrupt, which is implemented by allocating all or part of system events in a computing device to a coprocessing unit, thereby avoiding that the central processing unit cannot handle the entire system event for a long time in the conventional interrupt processing method. Running the application helps to improve the overall performance of the computing device.

The method for processing interrupts of the embodiment of the present application is exemplified below with reference to FIG. 3 to FIG. 5.

FIG. 3 is a schematic flowchart of a method for processing an interrupt according to an embodiment of the present application. It should be understood that the computing device in the method shown in FIG. 3 includes a co-processing unit and a central processing unit. See FIG. 1 for a specific structure. The method shown in FIG. 3 includes steps 310 through 330.

310. The coprocessing unit in the computing device receives the interrupt request sent by the interrupt source.

Specifically, the interrupt request is used to request the coprocessing unit to interrupt the currently running program and enter the interrupt processing process.

It should be noted that the interrupt request may be transmitted in the form of an interrupt signal or an interrupt message.

An optional implementation, the interrupt request is transmitted in the form of an interrupt signal. Specifically, the interrupt source and the co-processing unit are electrically connected, and the interrupt source can transmit an interrupt signal to the co-processing unit through the electrical connection, so that the interrupt signal can be sent to the co-processing unit through the pin of the co-processing unit. For example, in the X86 architecture, when the coprocessing unit is an SP in an Intel management engine (Intel ME) or a baseboard management controller (BMC), the interrupt request can be directly passed through the ME pin or The SP pin is sent to the ME or SP.

An optional implementation, the interrupt request is transmitted in the form of interrupt information. The interrupt source may configure the target node in the routing information of the interrupt request as a co-processing unit, and the interrupt source may transmit the interrupt request to the co-processing unit in the manner of interrupt information.

320. The coprocessing unit acquires a system event that triggers the interrupt request.

Specifically, after the coprocessing unit enters the interrupt processing flow, the system event corresponding to the interrupt request may be obtained. For example, the coprocessing unit can determine the interrupt source that sends the interrupt request by using the interrupt number carried in the interrupt request, and query the log recorded in the register of the interrupt source, and obtain the running state of the interrupt source from the log to obtain the running state. Get the system events that need to be processed.

The system event can be a type of business event generated by system activity and including system data. System events can include resource state changes, threshold violations, or abnormal system states and behaviors. Optionally, the system event may refer to an interrupt source that needs to send a current state of the interrupt source to the software system in the computing device, or the interrupt source needs to run a specific program through the software system in the computing device to cause the interrupt source to enter a working state.

330. The coprocessing unit processes the system event.

In particular, the co-processing unit can run the programs required to process system events to process system events. For example, if the interrupt source is a network card, and the system event is to log the network card fault to the log of the network card, the coprocessor can record the network card fault to the log of the network card.

Alternatively, different co-processing units can handle different types of system events. Specifically, when the coprocessing unit is a BMC, a system event that records the running status of the interrupt source may be processed. For example, the event that the NIC is faulty is recorded by the BMC to the log of the network card.

In the embodiment of the present application, the interrupt source in the computing device may directly send the interrupt request to the co-processing unit, request the co-processing unit to process the system event corresponding to the interrupt request, and process all the systems in the computing device with respect to the central processing unit. In the traditional solution of the event, the central processing unit is prevented from running the application or the OS for a long period of time due to processing of the system event, and the central processing unit can continue to run the application or the OS in the device processing the system event in the coprocessing unit. , improving the overall performance of computing devices.

Optionally, as an embodiment, the method further includes: the coprocessing unit enters an interrupt according to the interrupt request; and the coprocessing unit exits the interrupt when the system event is processed.

The coprocessing unit exits the interrupt when the system event is processed, and continues to run the previously interrupted program. That is, after the coprocessing unit replaces the central processing unit to share the processing system event, the program previously interrupted by the coprocessing unit can be continued to run.

Optionally, as an embodiment, the method further includes: the interrupt source generates an interrupt request; the interrupt source query interrupt distribution policy determines a target processing unit corresponding to the interrupt request, where the interrupt distribution policy includes: A type of interrupt request is processed by the CPU, and a second type of interrupt request is processed by the co-processing unit; when the interrupt request is the second type of interrupt request, step 310 is performed.

It should be noted that when the interrupt request is the second type of interrupt request, the second type of interrupt request is processed by the co-processing unit, and the co-processing unit has the capability of processing the second type of interrupt request. Alternatively, the CPU may also have the ability to process a second type of interrupt request.

The first type of interrupt request is processed by the central processing unit CPU while the CPU has the ability to process the first type of interrupt request. Alternatively, the co-processing unit may not have the ability to process the first type of interrupt request. For example, the co-processing unit cannot acquire a system event that triggers the first type of interrupt request, and therefore, the system event cannot be processed.

In the embodiment of the present application, for the same interrupt source, different types of interrupt requests of the interrupt source are allocated to different target processing unit processing by interrupting the distribution policy. For example, different types of interrupts are assigned based on the processing capabilities of different target processing units. Thereby, it is beneficial to improve the efficiency of the target processing unit processing system events.

Optionally, the interrupt distribution policy may be in the form of an interrupt sub-publishing for recording a mapping relationship between multiple types of interrupt requests and a plurality of processing units, the plurality of types including the first type And the second type, the plurality of processing units including the central processing unit and the co-processing unit.

The interrupt sub-publishing can record the correspondence between the interrupt request type and the routing information, and the routing information is used to route the interrupt request to the target processing unit. The interrupt source may query the interrupt sub-publishing to determine routing information corresponding to the interrupt request, and may route the interrupt request to the target processing unit based on the determined routing information.

It should be noted that the routing information may include a port number of a port through which the interrupt request is transmitted, or a routing address of the target processing unit. In a possible alternative implementation, in the case that the interrupt source of the computing device has a one-to-one correspondence with the target processor that processes the system event generated by the interrupt source, the interrupt source may not store the interrupt sub-publish, but directly interrupt the request. Send to the target processing unit corresponding to the interrupt source.

Optionally, the second type of interrupt request is a fault type interrupt request. If the interrupt source detects that it has failed, the second type indicates the type of fault of the interrupt source. If the interrupt source is used to detect other devices or to detect other devices of the computing device, the second type indicates the type of fault detected by the interrupt source.

Hereinafter, a method of processing an interrupt according to another embodiment of the present application will be described with reference to FIG. 4 based on a schematic block diagram of the computing device 100 shown in FIG. 1.

FIG. 4 is a schematic flowchart of a method for processing an interrupt according to an embodiment of the present application. The method illustrated in FIG. 4 includes steps 410 through 430. It should be noted that the noun description used in the method shown in FIG. 4 is the same as the noun description used in the method shown in FIG. 3, and can be understood as having the same meaning. For the sake of brevity, the method shown in FIG. No specific introduction is made.

410. The central processing unit receives an interrupt request sent by the interrupt source.

Specifically, after receiving the interrupt request, the central processing unit interrupts the currently running program and enters an interrupt processing flow.

420. The central processing unit acquires a system event that triggers the interrupt request.

Specifically, after entering the interrupt processing flow, the central processing unit may acquire a system event that triggers the interrupt request according to the interrupt request. For example, the central processing unit may determine the interrupt source that sends the interrupt request by using the interrupt number carried in the interrupt request, and query the log recorded in the register of the interrupt source, and obtain the running state of the interrupt source from the log to obtain the running state. Get the system events that need to be processed.

430. The central processing unit instructs the coprocessing unit to process the system event.

Optionally, the central processing unit may determine a co-processing unit that processes the system event by querying an event distribution policy, where the event distribution policy is used to indicate a co-processing unit that processes the system event, and the event distribution policy includes multiple types of system events. A mapping relationship with multiple coprocessing units. Thereby the central processing unit can send a system event to the determined co-processing unit.

It should be understood that the above event distribution policy may be preset by the central processing unit at the factory, or may be configured by the user during use.

In the embodiment of the present application, the central processing unit may allocate different types of system events to different co-processing unit processing through an event distribution policy. For example, different types of system events are assigned based on the processing capabilities of different co-processing units. Thereby improving the efficiency of the coprocessing unit processing system events.

Optionally, the event distribution policy may be embodied in the form of event sub-publishing, and the event sub-publishing records a mapping relationship between multiple types of system events and multiple co-processing units.

A possible specific implementation manner, the event sub-publishing can record the correspondence between the type of the system event and the routing information, and the routing information is used to route the system event to the co-processing unit. The central processing unit may query the event sub-publishing to determine routing information corresponding to the system event, and may route the system event to the corresponding co-processing unit based on the determined routing information.

It should be noted that the routing information may include a port number of a port through which a system event is transmitted, or a routing address of a coprocessing unit, and the like.

For example, when the system event is to process the running state of the recording interrupt source, the central processing unit may indicate that the coprocessing unit that processes the system event is the BMC.

In the embodiment of the present application, the central processing unit instructs the coprocessing unit to process the system event, and the central processing unit is prevented from processing the system due to processing system events, compared to the scheme in which the central processing unit processes all system events in the computing device. The application or OS cannot be run for a long period of time, improving the overall performance of the computing device.

Optionally, the central processing unit may further determine whether to instruct the coprocessing unit to process the system event according to the following three preset rules, where the central processing unit determines whether to instruct the coprocessing unit to process the system event according to the type of the system event. Preset rule 2, when the load of the central processing unit is higher than the target threshold, the coprocessing unit is instructed to process the system event; the preset rule 3, the central processing unit instructs the coprocessing unit to process the sub-event in the system event, so as to cooperate with the co-processing unit Collaborate on system events.

The method for processing an interrupt request in the embodiment of the present application is described below based on the preset rule 1.

As a possible implementation manner of the implementation step 430, the central processing unit may instruct the coprocessing unit to process the system event when the type of the system event is a target type, and the target type indicates the coprocessing unit Process system events with the target type.

Specifically, the target type indicates that the co-processing unit processes system events having the target type, and the co-processing unit also has the ability to process system events of the target type.

For example, when the system event is a correctable error when recording read data, only the correctable error at the time of reading the data needs to be recorded in the log. This implementation of system events that record correctable errors in reading data in the log can be handled separately by the co-processing unit. Therefore, the type of system event that can correct the error when reading the data is the target type.

It should be understood that when the target type of system event includes multiple sub-events, at least one of the plurality of sub-events may be assigned to the co-processing unit for processing.

If the type of the system event is the target type, the system event includes a plurality of sub-events, and in the step 430, the central processing unit may instruct the co-processing unit to process at least one of the plurality of sub-events Sub-event. Optionally, the sub-events that are not indicated to the co-processing unit among the plurality of sub-events may be processed by the central processing unit.

Specifically, the sub-event that is not indicated to the co-processing unit among the plurality of sub-events may include sub-events other than the at least one sub-event of the plurality of sub-events.

In the process in which the central processing unit and the co-processing unit cooperate to process system events, the sub-events respectively processed by the central processing unit and the co-processing unit may be determined by preset processing rules. For example, the preset processing rule may be set to the coprocessing unit to process the first type of sub-events of the plurality of sub-events, where the first-type sub-event refers to the sub-event that satisfies the target type among the plurality of sub-events; The at least one sub-event satisfies the target type and belongs to the first-type sub-event; the preset rule may be set to the central processing unit to process the second-type sub-event of the plurality of sub-events, the second-type sub-event refers to the multi-event A sub-event to the co-processing unit is not indicated in the sub-event, that is, a sub-event other than the at least one sub-event among the plurality of sub-events.

One possible design, the target type is that it can be processed by the co-processing unit. The first type of sub-event may be a sub-event processed by a co-processing unit, which may be a sub-event that must be processed by a central processing unit.

The first type of sub-event that satisfies the target type is processed by the co-processing unit, and the second type of sub-events of the plurality of sub-events not indicated to the co-processing unit are processed by the central processing unit, that is, by the co-processing unit and the central processing unit Collaborative processing of system events is beneficial to reducing the time that the central processing unit handles system events and improving the overall performance of the computing device.

It should also be understood that the embodiment of the present application does not limit the relationship between the first type of sub-event and the second type of sub-event in the processing time, for example, the plurality of sub-events included in the first-type sub-event and the second type The plurality of sub-events included in the sub-event can be cross-processed in processing time.

The method for processing an interrupt request in the embodiment of the present application is described below based on the preset rule 2.

As a possible implementation manner of the implementation step 430, the CPU acquires current load information of the CPU; the CPU indicates the co-processing when the load of the CPU indicated by the current load information is higher than a target threshold. The unit processes the system event.

Specifically, when the load of the CPU is higher than the target threshold, it can be understood that the current load of the CPU is in a high load state.

It should be noted that the load of the CPU may be specifically represented by parameters such as the occupancy rate of the computing resources of the CPU, the occupancy rate of the storage resources of the CPU, or the number of tasks to be processed by the CPU. The embodiment of the present application does not limit the specific embodiment of the load of the CPU.

It should also be understood that the target threshold may be preset, for example, may be preset by the CPU at the factory, or may be set by the user during the process of using the CPU. This embodiment of the present application does not specifically limit this.

In the embodiment of the present application, when the load of the CPU is higher than the target threshold, the CPU may instruct the coprocessing unit to process the system event, although processing the system event by the coprocessing unit may reduce the efficiency of processing the system event, but avoiding the CPU Handling system events and interrupting the currently running application or OS helps to increase the efficiency of the computing device.

Optionally, if the CPU is less than or equal to a target threshold indicated by the current load information, the CPU processes a system event that triggers the interrupt request.

That is, the CPU can handle system events by itself when the CPU load is below or equal to the target threshold.

When the CPU load is below or equal to the target threshold, the efficiency of the CPU processing system events is higher relative to the efficiency of the co-processing unit handling system events. Therefore, when the CPU load is lower than or equal to the target threshold, the CPU event can be handled by the CPU itself, which is beneficial to improve the efficiency of processing system events.

Optionally, the preset rule 1 and the preset rule 2 may also be used in combination. For example, when the load of the CPU is higher than the target threshold, and the type of the system event is the target type, the CPU may instruct the coprocessing unit to process the system event. .

It should be noted that the CPU may instruct the coprocessing unit to process system events. It can be understood that the coprocessing unit can perform all operations required to process system events; or, when the system event includes multiple sub-events, the CPU can indicate co-processing. The unit processes at least one of the plurality of sub-events.

For the case where the co-processing unit can perform all the operations required to process the event of the target system, or the co-processing unit processes at least one sub-event, refer to the detailed description in the pre-set rule one above, and for the sake of brevity, no further description is provided herein. .

The method for processing an interrupt request in the embodiment of the present application is described below based on the preset rule 3.

As one possible implementation of the implementing step 430, the system event includes a plurality of sub-events, and the CPU instructs the co-processing unit to process at least one of the plurality of sub-events. Optionally, sub-events other than the at least one sub-event of the plurality of sub-events may be processed by the central processing unit.

In the process in which the central processing unit and the co-processing unit cooperate to process system events, the sub-events respectively processed by the central processing unit and the co-processing unit may be determined by preset processing rules. For example, the preset processing rule may be set to the coprocessing unit to process the first type of sub-events of the plurality of sub-events, the first type of sub-events including the at least one sub-event; the preset system event processing rule may be set to be centrally processed The unit processes a second type of sub-events of the plurality of sub-events, the second type of sub-events including sub-events of the plurality of sub-events other than the at least one sub-event.

In a possible design, the first type of sub-event can be a sub-event that the co-processing unit has the ability to process, and the second-type sub-event can be a sub-event that the co-processing unit cannot process. The sub-event that the co-processing unit cannot process may refer to that the co-processing unit does not have the permission to process the sub-event, or the co-processing unit does not have the mechanism for processing the sub-event, and the specific embodiment of the present application is not applicable to the sub-event that the co-processing unit cannot process. The reason is not limited.

Optionally, as an embodiment, the preset rule 3 may be used in combination with the preset rule 2. The method further includes: the CPU acquiring current load information of the CPU; and the CPU is at the current load. When the load of the CPU indicated by the information is higher than the target threshold, at least one sub-event is selected from the plurality of sub-events. Further, the CPU instructs the co-processing unit to process the selected at least one sub-event.

It should be understood that the foregoing detailed description of the preset rule 2 is applicable to the scheme in which the preset rule 3 and the preset rule 2 are used in the embodiment of the present application. For brevity, details are not described herein again.

Optionally, as an embodiment, the preset rule 3 is further used in combination with the preset rule 1. The method further includes: the CPU selecting, from the multiple sub-events, at least one sub-event matching the target type. The target type instructs the co-processing unit to process a sub-event having the target type. Further, the CPU instructs the co-processing unit to process the selected at least one sub-event.

Specifically, the sub-event of the target type has the same properties as the sub-event of the target type described above, that is, all sub-events that the co-processing unit is capable of processing.

It should be noted that the sub-event of the target type may be pre-stored. For example, when the CPU is shipped from the factory, the sub-event of the target type can be integrated inside the computing device or inside the CPU, so that the CPU can find out the target type of sub-event from the system event to be processed.

Hereinafter, a method of processing an interrupt according to another embodiment of the present application will be described with reference to FIG. 5 based on a schematic block diagram of the computing device 100 shown in FIG. 1.

FIG. 5 is a schematic flowchart of a method for processing an interrupt according to an embodiment of the present application. The method shown in FIG. 5 includes steps 510 to 530. It should be noted that the description of the nouns in the method shown in FIG. 5 or the specific manner of implementing the method can be referred to the related descriptions in FIG. 3 and FIG. 4. For the sake of brevity, the method shown in FIG. 5 is not specifically described.

510. The central processing unit receives an interrupt request sent by the interrupt source.

520. The central processing unit directly forwards the interrupt request to the coprocessing unit, and the coprocessor unit processes the system event that triggers the interrupt request.

Specifically, the central processing unit forwards the interrupt request to the co-processing unit. After receiving the interrupt request, the co-processing unit may determine a system event that triggers the interrupt request based on the interrupt request, and process the system event.

It should be noted that the specific process of determining the system event that triggers the interrupt request based on the interrupt request may be referred to the specific process of the system event that triggers the interrupt request by the coprocessing unit described above.

Optionally, the interrupt request may be transmitted by the central processing unit to the co-processing unit with an interrupt signal or interrupt information to instruct the co-processing unit to process the system event corresponding to the interrupt request.

In an optional implementation manner, when the interrupt request is transmitted by using the interrupt information, the interrupt information may carry a system event that triggers the interrupt request, and the co-processing unit may directly acquire the system event from the interrupt information, without using the prior art. The central processing unit acquires system events in a manner that acquires system events. It is beneficial to simplify the steps of the coprocessing unit to acquire system events.

On the other hand, by carrying the system event that triggers the interrupt request in the interrupt information, the situation that the co-processing unit cannot process the system event due to the inability to acquire the system event is avoided, and the possibility that the co-processing unit handles the system event is improved.

In an optional implementation manner, when the interrupt request is transmitted in the manner of interrupt information, the interrupt information may also be the same as the interrupt signal, and only notify the coprocessing unit to enter the interrupt processing program without indicating the content of the coprocessing unit system event. At this time, the co-processing unit needs to acquire the system event by using the central processing unit in the prior art to acquire the system event.

The signaling overhead caused by the transmission interruption information is reduced by reducing the content of the information carried in the interrupt information.

As a possible implementation of the implementation step 520, the central processing unit forwards the interrupt request directly to the coprocessing unit when the load of the CPU is higher than the target threshold.

Before the step 520, the method further includes: the CPU queries the interrupt forwarding policy, and determines a co-processing unit that processes the system event, where the interrupt forwarding policy is used to indicate a target processing unit that processes the system event, and the CPU determines that the interrupt request corresponds to When the target processing unit is the co-processing unit, step 520 is performed.

Specifically, the interrupt forwarding policy is further used to indicate a mapping relationship between multiple types of interrupt requests and multiple coprocessing units, that is, the interrupt forwarding policy records a coprocessing unit that processes different types of interrupt requests in multiple types of interrupt requests. .

The target processing unit is a co-processing unit that can process the interrupt request.

In the embodiment of the present application, the CPU allocates different types of interrupt requests to different target processing units by interrupting the forwarding policy, that is, assigning different types of system events based on the processing capabilities of different target processing units, which is beneficial to improving the target. The processing unit handles the efficiency of system events.

Optionally, the interrupt forwarding policy may be embodied by an interrupt forwarding table. Specifically, the interrupt forwarding table may record a correspondence between the interrupt request type and the routing information, and the routing information is used to route the interrupt request to the target processing unit. The CPU may query the interrupt forwarding table to determine routing information corresponding to the interrupt request, and may route the interrupt request to the target processing unit based on the determined routing information.

It should be noted that the interrupt forwarding table can be stored in the memory of the computing device.

A possible implementation manner, in the case that the number of target processing units for processing system events in the computing device is 1, that is, when only one coprocessing unit can process system events, the CPU may not store the interrupt forwarding policy, but directly interrupts The request is sent to the co-processing unit.

Hereinafter, in conjunction with FIG. 6, a method for cooperating a system event by a central processing unit and a coprocessing unit is illustrated by taking a system event generated by adding a memory stick for a computing device online as an example. The process of specifically processing system events can be divided into four processing flows: powering the memory module, initializing the memory module, assigning a physical address to the memory module, and notifying the OS to use the memory module.

FIG. 6 is a schematic flowchart of a method for a central processing unit and a coprocessing unit to jointly process a system event according to an embodiment of the present application. The method shown in FIG. 6 includes steps 610 to 611.

Process one, powering the memory module.

601. The coprocessing unit receives an IPMI message sent by the central processing unit, where the IPMI message is used to instruct the coprocessing unit to interrupt the currently running program for processing a system event.

602. The coprocessing unit determines, according to the preset rule, that the coprocessing unit needs to supply power to the newly added memory module in the process of processing the system event.

Specifically, the co-processing unit may be an SP on the BMC.

603. The coprocessing unit supplies power to the memory module.

604. The coprocessing unit notifies the central processing unit that the operation of powering the memory module is completed.

Specifically, the co-processing unit operates a status bit in the register, by which the operation of the memory strip power supply is completed, and then the co-processing unit transmits execution completion information to the central processing unit. The central processing unit receives the execution completion information, queries the status bits in the register, and knows that the memory module is powered.

It should be noted that the status bit for the central processing unit to query may be a status bit pre-determined by the co-processing unit and the central processing unit for indicating whether the operation of the power supply of the memory module is completed.

It should be understood that the execution completion information may be an interrupt signal. Specifically, the coprocessor may trigger the interrupt signal through a General Purpose Input Output (GPIO) pin on a Platform Controller Hub (PCH). .

605, after the memory card is successfully powered on, the corresponding power-on status bit becomes valid, and the co-processing unit reads the valid power-on state.

Process flow 2, initialize the memory module.

606. The coprocessing unit performs an operation of initializing the memory module.

Specifically, the operation of initializing the memory module may include configuring electrical parameters for the memory module and the memory data bus, and performing self-checking on the memory module.

It should be noted that, after the co-processing unit completes the operation of initializing the memory module, the manner of notifying the central processing unit can be referred to the manner in which the co-processing unit notifies the central processing unit in the process flow 1. For brevity, no further details are provided herein.

In the embodiment of the present application, the process of initializing the memory module takes a long time. Since the coprocessing unit replaces the central processing unit to initialize the memory module, the central processing unit can be free from the system event (for initializing the memory module) for a long time. Impact, the central processing unit can execute the application during this time, which helps to improve the overall performance of the computing device.

Process 3, assigning a physical address to the memory module.

607. The coprocessing unit writes the memory address of the memory module to a shadow register of the central processing unit.

608. The coprocessor processing unit notifies that the memory address of the central processing unit memory module has been written into the shadow register of the central processing unit.

It should be noted that, the manner in which the co-processing unit notifies the central processing unit can refer to the manner in which the co-processing unit notifies the central processing unit in the process flow 1. For brevity, no further details are provided herein.

609. The central processing unit initiates a silent process.

Specifically, the silent process may refer to the central processing unit notifying all central processing units, caches, and memory controller tentative actions in the computing device, so that the central processing unit copies the data of the shadow register into the register having the actual control function, and The memory controller can establish a mapping relationship between the memory address and the physical address based on the data in the register.

610. The central processing unit initiates the release of the silence notification, and the central processing unit, the cache, and the memory controller in the computing device resume operation.

It should be noted that, based on the current computing device architecture, the silent process requires the central processing unit to issue special broadcast messages, and thus belongs to operations that can only be performed by the central processing unit.

Process 4, the BIOS notifies the OS to use the memory module.

611. The BIOS running in the central processing unit notifies the OS to use the memory module.

It should be noted that because the BIOS needs to run in the central processing unit, step 611 can only be processed by the central processing unit.

The method for processing interruption of the embodiment of the present application is described in detail above with reference to FIG. 1 to FIG. 6. The apparatus for processing interrupt in the embodiment of the present application is described in detail below with reference to FIG. 7 to FIG. It should be noted that the apparatus shown in FIG. 7 to FIG. 12 can implement various steps in the method, and details are not described herein for brevity.

FIG. 7 is a schematic block diagram of an apparatus for processing an interrupt according to an embodiment of the present application. The apparatus 700 shown in FIG. 7 may be a CPU in a computing device, and the apparatus shown in FIG. 7 includes a receiving module 710 and a processing module 720.

The receiving module 710 is configured to receive an interrupt request.

The processing module 720 is configured to acquire a system event corresponding to the interrupt request, where the system event includes processing information of the interrupt request.

The processing module 720 is configured to instruct the coprocessing unit to process the system event.

Optionally, as an embodiment, the processing module 720 is specifically configured to: acquire current load information of the CPU; and indicate, when the load of the CPU indicated by the current load information is higher than a target threshold. The descriptive processing unit processes the system event.

Optionally, as an embodiment, the processing module 720 is specifically configured to: when the type of the system event is a target type, instruct the coprocessing unit to process the system event, where the target type indicates the The co-processing unit processes system events having the target type.

Optionally, as an embodiment, the system event includes multiple sub-events, and the processing module 720 is specifically configured to instruct the co-processing unit to process at least one of the plurality of sub-events.

Optionally, as an embodiment, the processing module 720 is further configured to: acquire current load information of the CPU; and when the load of the CPU indicated by the current load information is higher than a target threshold, The at least one sub-event is selected from the plurality of sub-events.

Optionally, as an embodiment, the processing module 720 is further configured to: select a sub-event matching the target type from the multiple sub-events, where the sub-event matching the target type is the at least one sub-event An event, the target type indicating that the co-processing unit processes a sub-event having the target type.

Optionally, as an embodiment, the processing module 720 is further configured to process a sub-event of the plurality of sub-events except the at least one sub-event.

Optionally, as an embodiment, the processing module 720 is further configured to: enter an interrupt according to the interrupt request; when processing a sub-event other than the at least one sub-event in the plurality of sub-events, Exit the interrupt.

In an optional embodiment, the receiving module 710 can be an input/output interface 810 in the central processing unit. The processing module 720 can be a control component 820 in the central processing unit. The central processing unit 800 further includes a register component 830. As shown in Figure 8.

FIG. 8 is a schematic block diagram of a central processing unit of an embodiment of the present application. The central processing unit shown in FIG. 8 may include an input and output interface 810, a control unit 820, and a register unit 830. Wherein, the input/output interface 810, the control unit 820, and the register 830 are connected through an internal connection path, the control unit is configured to decode the instruction, and issue a control signal for each operation to be performed for each instruction, and the register component is used for saving The register operands and operation results temporarily stored during the execution of the instruction. The input and output interfaces are used to receive input data and information, and output data operation results and other data.

It should be noted that at least one register may be included in the register component. Specifically, the register component may include at least one of a register, a special register, and a control register.

In the implementation process, the steps of the method may be completed by an integrated logic circuit of the hardware of the computing device or an instruction in the form of software. The method disclosed in the embodiment of the present application may be directly implemented as a hardware central processing unit, or may be performed by a combination of hardware and software modules in a central processing unit. The software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like. The storage medium can be located in a memory in the computing device, and the central processing unit reads the information in the memory and, in conjunction with its hardware, performs the steps of the method. To avoid repetition, it will not be described in detail here.

FIG. 9 is a schematic block diagram of an apparatus for processing an interrupt according to an embodiment of the present application. The apparatus 900 shown in FIG. 9 includes an acquisition module 910, a processing module 920, and a receiving module 930.

The obtaining module 910 is configured to obtain a system event that is processed by the central processing unit CPU, and the system event indicated by the CPU is a system event that is acquired by the CPU when the interrupt request is received. The system event includes processing information of the interrupt request;

The processing module 920 is further configured to process the acquired system event.

Optionally, as an embodiment, the receiving module 930 is configured to receive an interrupt request sent by the interrupt source, and the acquiring module 930 is further configured to acquire a system event corresponding to the interrupt request received by the coprocessing unit.

In an optional embodiment, the receiving module 930 can be an input/output interface 1010 in the coprocessing unit, and the processing module 920 and the obtaining module 930 can be a control component 1020 in the coprocessing unit, and the coprocessing unit 1000 further includes a register. The component 1030 is specifically as shown in FIG.

FIG. 10 is a schematic block diagram of a co-processing unit of an embodiment of the present application. The coprocessing unit 1000 shown in FIG. 10 may include an input and output interface 1010, a control unit 1020, and a register unit 1030. The input/output interface 1010, the control unit 1020, and the register 1030 are connected by an internal connection path, and the control unit is configured to decode the instruction and issue a control signal for each operation to be performed for each instruction, and the register is used to save the instruction. The register operands and operation results temporarily stored during execution, and the input and output interfaces are used to receive input data and information, and output data operation results and other data.

In the implementation process, the steps of the method may be completed by an integrated logic circuit of hardware in the computing device or an instruction in the form of software. The method disclosed in the embodiment of the present application may be directly implemented as a hardware co-processing unit, or may be performed by a combination of hardware and software modules in the co-processing unit. The software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like. The storage medium is located in a memory of the computing device, and the coprocessing unit reads the information in the memory and completes the steps of the method in conjunction with its hardware. To avoid repetition, it will not be described in detail here.

11 is a schematic block diagram of an apparatus for processing an interrupt according to an embodiment of the present application. The apparatus 1100 shown in FIG. 11 includes: a generating module 1111, a processing module 1120, and a sending module 1130.

a generating module 1110, configured to generate an interrupt request;

The processing module 1120 is configured to query the interrupt distribution policy to determine a target processing unit corresponding to the interrupt request, where the interrupt distribution policy includes: the first type of interrupt request is processed by the central processing unit CPU, and the second type of interrupt request is processed by the co-processing Unit processing

The sending module 1130 is configured to send the interrupt request to a target processing unit corresponding to the interrupt request.

Optionally, as an embodiment, the second type of interrupt request is a fault type interrupt request.

In an optional embodiment, the device 1100 may also be an interrupt source 1200. Specifically, the generating module 1110 and the processing module 1120 may be a controller 1210. The sending module 1130 may be an input/output interface 1220. 12 is shown.

FIG. 12 is a schematic block diagram of an interrupt source of an embodiment of the present application. The interrupt source 1200 shown in FIG. 12 may include a controller 1210 and an input/output interface 1220. The controller 1210 and the input/output interface 1220 are connected through an internal connection path for controlling the input/output interface to receive input data and information, and outputting operation results and the like.

It should be noted that the controller 1210 shown in FIG. 12 can be located inside the interrupt source, and can also be understood as a controller that controls the interrupt source, that is, two separate devices from the interrupt source.

It should be understood that in the embodiment of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should also be understood that determining B from A does not mean that B is only determined based on A, and that B can also be determined based on A and/or other information.

It should be understood that the term "and/or" herein is merely an association relationship describing an associated object, indicating that there may be three relationships, for example, A and/or B, which may indicate that A exists separately, and A and B exist simultaneously. There are three cases of B alone. In addition, the character "/" in this article generally indicates that the contextual object is an "or" relationship.

It should be understood that, in the various embodiments of the present application, the size of the sequence numbers of the processes does not mean the order of execution, and the order of execution of each process should be determined by its function and internal logic, and should not be taken to the embodiment of the present application. The implementation process constitutes any limitation.

In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the device embodiments described above are merely illustrative. For example, the division of the unit is only a logical function division. In actual implementation, there may be another division manner, for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

In this embodiment, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes program code. When the program code is loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are generated in whole or in part. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transmission to another website site, computer, server, or data center by wire (eg, coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (eg, infrared, wireless, microwave, etc.). The computer readable storage medium can be any available media that can be read by a computer or a data storage device such as a server, data center, or the like that includes one or more available media. The usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a Digital Video Disc (DVD)), or a semiconductor medium (eg, a Solid State Disk (SSD)). )Wait.

The foregoing is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application. It should be covered by the scope of protection of this application. Therefore, the scope of protection of the present application should be determined by the scope of the claims.

Claims

A method for processing an interrupt, comprising:

The central processing unit CPU receives the interrupt request;

The CPU acquires a system event that triggers the interrupt request;

The CPU instructs the coprocessing unit to process the system event.
The method of claim 1, wherein the CPU instructs the coprocessing unit to process the system event comprises:

The CPU acquires current load information of the CPU;

The CPU instructs the coprocessing unit to process the system event when the load of the CPU indicated by the current load information is higher than a target threshold.
The method of claim 1, wherein the CPU instructs the coprocessing unit to process the system event comprises:

The CPU instructs the coprocessing unit to process the system event when the type of the system event is a target type, the target type instructing the coprocessing unit to process a system event having the target type.
The method of claim 1 wherein said system event comprises a plurality of sub-events,

The CPU instructs the coprocessing unit to process the system event, including:

The CPU instructs the coprocessing unit to process at least one of the plurality of sub-events.
The method of claim 4, wherein before the CPU instructs the co-processing unit to process at least one of the plurality of sub-events, the method further comprises:

The CPU acquires current load information of the CPU;

The CPU selects the at least one sub-event from the plurality of sub-events when a load of the CPU indicated by the current load information is higher than a target threshold.
The method of claim 4, wherein before the CPU instructs the coprocessing unit to process at least one of the plurality of sub-events, the method further comprises:

The CPU selects a sub-event matching the target type from the plurality of sub-events, the sub-event matching the target type is the at least one sub-event, the target type indicating that the co-processing unit processing has the Sub-event of the target type.
The method according to any one of claims 4 to 6, wherein the method further comprises:

The CPU processes a sub-event that is not indicated to the co-processing unit among the plurality of sub-events.
The method according to any one of claims 4 to 7, wherein the method further comprises:

The CPU enters an interrupt according to the interrupt request;

The CPU exits the interrupt when processing a sub-event that is not indicated to the co-processing unit in the plurality of sub-events.
A method for processing an interrupt, comprising:

The interrupt source generates an interrupt request;

The interrupt source query interrupt distribution policy determines a target processing unit corresponding to the interrupt request, and the interrupt distribution policy includes: a first type of interrupt request is processed by a central processing unit CPU, and a second type of interrupt request is processed by a coprocessing unit ;

The interrupt source sends the interrupt request to a target processing unit corresponding to the interrupt request.
The method of claim 9 wherein said second type of interrupt request is a fault type interrupt request.
A device for processing an interrupt, comprising:

a receiving module, configured to receive an interrupt request;

a processing module, configured to acquire a system event that triggers the interrupt request;

The processing module is configured to instruct the coprocessing unit to process the system event.
The device according to claim 11, wherein the processing module is specifically configured to:

Obtaining current load information of the CPU;

And when the load of the CPU indicated by the current load information is higher than a target threshold, instructing the coprocessing unit to process the system event.
The device according to claim 11, wherein the processing module is specifically configured to:

And when the type of the system event is a target type, instructing the co-processing unit to process the system event, the target type instructing the co-processing unit to process a system event having the target type.
The device of claim 11 wherein said system event comprises a plurality of sub-events,

The processing module is specifically configured to instruct the coprocessing unit to process at least one of the plurality of sub-events.
The device according to claim 14, wherein the processing module is further configured to:

Obtaining current load information of the CPU;

The at least one sub-event is selected from the plurality of sub-events when a load of the CPU indicated by the current load information is higher than a target threshold.
The device according to claim 14, wherein the processing module is further configured to:

Selecting a sub-event matching the target type from the plurality of sub-events, the sub-event matching the target type being the at least one sub-event, the target type indicating that the co-processing unit processes the target type Sub-event.
The device according to any one of claims 14 to 16, wherein the processing module is further configured to process a sub-event that is not indicated to the co-processing unit among the plurality of sub-events.
The device according to any one of claims 14 to 17, wherein the processing module is further configured to:

Entering an interrupt according to the interrupt request;

The interrupt is exited when a sub-event to the co-processing unit is not indicated in the plurality of sub-events.
A device for processing an interrupt, comprising:

Generating a module for generating an interrupt request;

a processing module, configured to query an interrupt distribution policy to determine a target processing unit corresponding to the interrupt request, where the interrupt distribution policy includes: a first type of interrupt request is processed by a central processing unit CPU, and a second type of interrupt request is processed by a coprocessing unit deal with;

And a sending module, configured to send the interrupt request to a target processing unit corresponding to the interrupt request.
The apparatus of claim 19 wherein said second type of interrupt request is a fault type interrupt request.
A central processing unit CPU, characterized in that the central processing unit executes program code to implement the method of any one of claims 1-8.
An interrupt source, characterized in that the interrupt source executes program code to implement the method of claim 9 or 10.
A computer readable medium storing program code; when the program code is run on a computing device, causing the computing device to perform the method of any of claims 1-8.
A computer readable medium storing program code; when the program code is run on a computing device, causing the computing device to perform the method of any one of claims 9 or 10.