JP2012009063A - Centralized interrupt controller - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an advanced programmable interrupt controller centralized with respect to a plurality of processing units.SOLUTION: The centralized interrupt controller having a single copy of APIC (advanced programmable interrupt controller) logic provides all the processing units of a multi-sequencer chip or a system with APIC interrupt providing services. An interrupt sequencer block of the centralized interrupt controller schedules the interrupt services according to a fairness scheme. At least one embodiment of the centralized interrupt controller has firewall logic for filtering out transmission of a selected interrupt message. Other embodiments are also written or requested.

Description

  The present invention relates to an electronic circuit for controlling interrupts or interrupts. More particularly, the present invention relates to an Advanced Programmable Interrupt Controller that is centralized for multiple processing units.

  The processing unit underlying the performance of the computer system performs several processes including control of various intermittent “services” requested by peripheral devices connected to the computer system. Input / output (I / O) peripheral devices, including computer items such as printers, scanners, display devices, etc., require the host processor to provide intermittent service to ensure proper functionality. For example, a service may include data transmission, data capture and / or control signals.

  Each peripheral device typically has a different service delivery schedule that depends not only on the device type, but also on its programmed use. The host processor multiplexes the provision of services between devices according to its own request while executing one or more background programs. At least two methods for advising the service host had to be used: polling and interrupt methods. In the former method, each peripheral device is periodically checked to confirm whether a flag indicating a service request is set. In the latter method, the device service request is forwarded to an interrupt controller capable of interrupting the host and a branch from its current program to a special interrupt service routine is executed. The interrupt method is effective because the host does not need to allocate unnecessary clock cycles for polling. It is this latter method that the present disclosure focuses on.

  With the advent of multiprocessor computer systems, interrupt management systems that dynamically distribute interrupts between processors have been realized. APIC (Advanced Programmable Interrupt Controller) is an example of a multiprocessor interrupt management system. The APIC interrupt transmission mechanism used in many multiprocessor computer systems detects an interrupt request from another processing unit or peripheral device and indicates that a specific service corresponding to the interrupt request needs to be executed. May be used to notify the above processing units. Further details regarding the APIC interrupt transmission system are described in US Pat. No. 5,283,904, “Multiprocessor Programmable Interrupt Controller System” by Carson et al.

  Many conventional APICs are designed with a large number of hardware and therefore require a large number of gates (ie, high gate counts). In many multiprocessor systems, each core has its own dedicated APIC that is completely self-contained within the core. In other multiprocessor systems, each core is a simultaneous multithreaded core with multiple logical processors. In such a system, each logical processor is associated with an APIC, each multithreaded core has multiple APIC interrupt transmission mechanisms, each mechanism maintaining its own architectural state and generally controlling all other APICs. Realize own control logic that is the same as logic. For any type of multiprocessor system, the cost of die area and leakage power for multiple APICs can be undesirably large. Further, because of the transmission of interrupts in a multiprocessor system, the dynamic power cost associated with the operation of multiple APICs can also be desirably high.

  An object of the present invention is to provide an advanced programmable interrupt controller that is centralized for a plurality of processing units.

  In order to solve the above-described problem, an aspect of the present invention performs a priority and control function for providing an interrupt message for a plurality of processing units, and a single logic block shared by the plurality of processing units; An interrupt sequencer block connected to the logic block for scheduling interrupt events of the plurality of processing units for processing by the logic block; and a storage area for maintaining respective architecture interrupt state information of the plurality of processing units; An apparatus having one or more input message queues for receiving an input interrupt message and placing information from the message in the storage area and one or more output message queues for transmitting an output interrupt message .

  According to the present invention, an advanced programmable interrupt controller can be provided that is centralized for a plurality of processing units.

FIG. 1 is a block diagram illustrating at least one embodiment of a centralized interrupt controller that provides interrupt control for a plurality of processing units. FIG. 2 is a block diagram illustrating further details of at least one embodiment of a centralized interrupt controller. FIG. 3 is a block diagram showing various embodiments of the multi-sequencer system. FIG. 4 is a block diagram illustrating at least one embodiment of a central repository in a multiple core interrupt state. FIG. 5 is a state transition diagram illustrating at least one embodiment of the operation of the interrupt sequencer block of the centralized interrupt controller. FIG. 6 is a block diagram illustrating at least one embodiment of a computing system capable of performing the disclosed techniques.

  In the following, selected embodiments of a method, system and product for centralized APIC of a plurality of processing units are described. Each mechanism described herein may be utilized by a single core or multi-core multi-thread system. In the following, numerous specific details such as processor type, multi-threaded environment, system configuration, and the number and type of sequencers in a multi-sequencer system are provided to provide a more complete understanding of the present invention. However, it will be understood by one skilled in the art that the present invention may be practiced without such specific details. Furthermore, well-known structures, circuits, etc., are not described in detail so as not to unnecessarily obscure the present invention.

  FIG. 1 is a block diagram illustrating at least one embodiment of a system 100 having a centralized interrupt controller 110. The system 100 includes a plurality of cores 104 (0) to 104 (n). The dashed lines and ellipses in FIG. 1 indicate that the system 100 can have any number n (n ≧ 2) cores. Those skilled in the art will recognize that other embodiments of the system can have a single simultaneous multi-threading (SMT) core (so that n = 1), as described below. There will be.

  FIG. 1 shows that a single centralized interrupt controller 110 is physically separated from the cores 104 (0) -104 (n). FIG. 1 also shows that each core 104 (0)-104 (n) of the system 100 is connected to a centralized interrupt controller 110 via the local interconnect 102. The centralized interrupt controller 110 interfaces with each processing core via the local interconnect 102. The high-level purpose of the centralized interrupt controller 110 is to make the operation of multiple APICs serially so that the APIC appears to the system 100 as if it were operating in parallel as in a conventional core-based APIC system. To imitate.

  A single core 104 of the system 100 can implement any of a variety of multithreading schemes including simultaneous multithreading (SMT), switch on event multithreading (SoeMT), and / or time multiplexed multithreading (TMUX). is there. If instructions from multiple hardware thread contexts (logical processors) are executed on the processor 304 at any point in time, it is called SMT. Alternatively, in a single core multithreading system, the processor pipeline is multiplexed between multiple hardware thread contexts, but only instructions from one hardware thread context are executed in the pipeline at a given time. SoeMT may be implemented. For SoeMT, if the thread switch event is time-based, it will be TMUX. Single cores that support SoeMT and TMUX can support multithreading, but they are referred to as “single thread” cores. This is because only instructions from one hardware thread context are executed at any given time.

  Each core 104 may be a single processing unit capable of executing a single thread. Alternatively, one or more cores 104 may be multi-threading cores that perform SoeMT or TMUX multi-threading so that instructions for one thread are only executed at that point in time. In such an embodiment, the core 104 is referred to as a “processing unit”.

  In at least one other embodiment, each core 104 is a multi-threaded core, such as an SMT core. For the SMT core 104, each logical processor of the core 104 is referred to as a “processing unit”. As used herein, a “processing unit” may be any physical or logical unit that can execute a thread. Each processing unit may have next instruction pointer logic to determine the next instruction to be executed for a given thread. A processing unit may also be used synonymously with “sequencer”.

  For either embodiment (single thread core and multi-thread core), each processing unit is provided by a centralized interrupt controller 110 where the logic of its interrupt controller functionality is not self-contained within each processing unit. If so, it is associated with the function. If any core 104 is an SMT core, each logical processor in each core 104 may be connected to a centralized interrupt controller 110 via the local interconnect 102.

  Referring to FIG. 3, as described above, a processing unit (or “sequencer”) may be a logical processor or a physical processor. In FIG. 3, the difference between the logical processing unit and the physical processing unit is shown. FIG. 3 is a block diagram illustrating selected hardware configurations of multi-sequencer system embodiments 310 and 350 capable of performing the disclosed techniques.

  FIG. 3 shows a selected hardware configuration for a single core multi-sequencer multi-threading environment 310. FIG. 3 also illustrates a selected hardware configuration of a multi-core multi-threading environment 350 where each sequencer is an independent physical processor core.

In single-core multithreading environment 310, a single physical processor 304 is made to appear as multiple logical processors that are referenced by the LP ₁ ~LP _n to the operating system and user programs (not shown). Each logical processor LP ₁ -LP _n maintains a complete set of architectural states AS ₁ -AS _n , respectively. This architectural state has most of the data registers, segment registers, control registers, debug registers and model specific registers for at least one embodiment. The logical processors LP ₁ -LP _n share most other resources of the physical processor 304 such as caches, execution units, branch predictors, control logic, and buses. However, each logical processor LP ₁ -LP _n may be associated with its own APIC.

  Although multiple hardware configurations are shared, each thread context in the multithreading environment 310 can independently generate the next instruction address (and, for example, from an instruction cache, an execution instruction cache, or a trace cache, etc. Fetch can be performed). Thus, the processor 304 has a logically independent next instruction pointer fetch logic 320 that fetches the instructions of each thread context even if multiple logical sequencers can be implemented in a single physical fetch / decode unit 322. . In the single-core multithreading embodiment, the term “sequencer” includes at least some of the thread context's associated architectural state 312 along with at least the next instruction pointer fetch logic of the thread context. It should be noted that the sequencer of single core multithreading system 310 need not be symmetric. For example, two single-core multithreading sequencers on the same physical core may differ in the amount of architecture state information they maintain.

  Thus, in at least one embodiment, multi-sequencer system 310 is a single core processor 304 that supports simultaneous multi-threading. For such an embodiment, each sequencer is a logical processor with the same physical processor core 304 executing all thread instructions, but with its own next instruction pointer fetch logic and its own architecture state information. For such an embodiment, a logical processor may maintain a version of its architectural state, although the execution resources of a single processor core may be shared among threads executing simultaneously.

  FIG. 3 also illustrates at least one embodiment of a multi-core multi-threading environment 350. Such an environment 350 has two or more independent physical processors 304a-304n each capable of executing different threads / shreds so that execution of at least some of the different threads / shreds can proceed simultaneously. Each processor 304a-304n has a physically independent fetch unit 322 to fetch instruction information for its own thread or shred. In an embodiment where each processor 304a-304n executes a single thread / shred, the fetch / decode unit 322 implements a single next instruction pointer fetch logic 320. However, in embodiments where each processor 304a-304n supports multiple thread contexts, fetch / decode unit 322 implements different next instruction pointer fetch logic 320 for each supported thread context. The optional nature of the additional next instruction pointer fetch logic 320 in the multiprocessor environment 350 is illustrated in FIG.

  For at least one embodiment of the multi-core system 350 shown in FIG. 3, each sequencer may be a processor core 304 having multiple cores 304a-304n in a single chip package 360. Each core 304a-304n may be a single thread or multi-thread processor core. Chip package 360 is indicated by a dashed line in FIG. 3 to indicate that the illustrated single chip embodiment of multi-core system 350 is merely an example. In other embodiments, the processor cores of a multi-core system may reside on separate chips. That is, the multi-core system may be a multi-socket symmetric multi-processing system.

  For simplicity of explanation, the following description focuses on an embodiment of the multi-core system 350. However, this focus should not be construed as limiting in that the mechanisms described below can be executed in either multi-core or single-core multi-sequencer environments.

  Referring to FIG. 1, it can be seen that the cores 104 (0)-104 (n) of the system 100 can be connected to each other via the local interconnect 102. The local interconnect 102 may provide all communication functions required between cores (such as cache snoop). Each core 104 (0)-104 (n) may have a relatively small interface block for sending and receiving interrupt related messages over the local interconnect 102. In general, such an interface of the core does not maintain the architectural state for interrupt-related messages and it does not perform other related functions performed by the centralized interrupt controller 110 described herein. Or is not relatively prioritized, so it is relatively simple.

  Cores 104 (0) -104 (n) may be on a single die 150 (0). For at least one embodiment, the system 100 shown in FIG. 1 may further have optional additional dies. The optional nature of one or more additional dies (˜150 (n)) is indicated in FIG. 1 by dashed lines and ellipses. FIG. 1 shows that an interrupt message from a processing unit on the other die (150 (n)) is communicated to the first die (150 (0)) via the system interconnect. The centralized interrupt controller 110 is connected to any other die (˜150 (n)) and peripheral I / O devices 114 via the system interconnect 106.

  Those skilled in the art will recognize that the configuration of the die 150 shown in FIG. 1 is merely an example and should not be construed as limiting. In other embodiments, for example, both 150 (0) and 150 (n) elements may reside in the same silicon portion and be connected to the same local interconnect 102. On the other hand, each core 104 does not necessarily have to reside on the same chip. Each core 104 (0) -104 (n) and / or local interconnect 102 may not reside on the same die 150.

  Each core 104 (0) -104 (n) of the system 100 may further be connected to other system interface logic 112 via the local interconnect 102. Such logic 112 may include, for example, cache coherence logic or other interface logic that allows the sequencer to interface with other system elements via the system interconnect. Other system interface logic 112 may also be connected to other system elements 116 (such as memory) via system interconnect 106.

  FIG. 2 is a block diagram illustrating further details of at least one embodiment of the centralized interrupt controller 110. In general, FIG. 2 shows that the centralized interrupt controller 110 is physically separate from the core of the system (such as cores 104 (0) -104 (n) of FIG. 1), but the centralized interrupt controller 110 indicates that the complete architectural state of each APIC instance associated with each sequencer is maintained. A centralized interrupt controller 110 manages all of the interrupt queuing and prioritization functions normally handled by a dedicated APIC per core of conventional systems. As described in detail below, the centralized interrupt controller 110 may also function as a firewall between the rest of the system connected to the system interconnect 106 and the sequencer.

  FIG. 2 shows that the centralized interrupt controller 110 has a centralized APIC state 202. The APIC state 202 includes architectural states that are typically associated with typical APIC processing. That is, APIC processing is architecturally visible to application programmers, and such an interface is not intended to be modified by the present disclosure. Regardless of whether the system has conventional APIC hardware (ie, one self-contained APIC for each processing unit) or a centralized interrupt controller as described herein, for at least one embodiment, this It is expected that such hardware design choices should be transparent to the application programmer. In this way, the area, dynamic power, and power leak costs are utilized by the system's single centralized interrupt controller 110 while simultaneously maintaining the same architectural interface expected by operating system vendors and application programmers. Can be reduced.

For this reason, the architectural state maintained as the central repository of APIC state information in block 202 is generally the state maintained for each APIC in conventional systems. For example, if there are 8 sequencers in the system, the centralized APIC state 202 may include an array of 8 entries that reflect the architectural APIC state where each entry is maintained for the sequencer of the conventional system. (The description of FIG. 4 below indicates that each entry also includes a specific microarchitecture state.)
For at least one embodiment, the centralized APIC state 202 is implemented as a single memory storage area, such as a register file or an array. The register file configuration may allow better area efficiency than conventional approaches that implement core unit APIC states as random logic.

  In general, the centralized interrupt controller 110 monitors receipt of interrupt messages received via the local interconnect 102 and / or the system interconnect 106 and stores messages associated with the appropriate entries in the register file 202. In at least one embodiment, this is accomplished by monitoring the destination address of the incoming message and storing the message in the APIC instance entry associated with the destination address. Such functions may be performed by the input message queues 204, 206, as will be described in detail below.

  Similarly, the centralized interrupt controller 110 may monitor the generation of output interrupt messages and store the messages in the appropriate entries in the register file 202 until such messages are serviced and transmitted. In at least one embodiment, this is accomplished by monitoring the source address of the outgoing message and storing the message in the APIC instance entry associated with the source address. Such a function may be performed by output message sequences 208, 210, as described in detail below.

  In general, the interrupt sequencer block 214 of the centralized interrupt controller 110 may then schedule pending interrupt messages to be reflected in the centralized APIC state 202 for service. As will be explained in detail below, this may be implemented according to a fairness scheme so that any pending interrupt operations of the sequencer are not repeatedly ignored. The interrupt sequencer block 214 may call the APIC interrupt provision logic 212 to perform the service.

  FIG. 2 shows that the centralized interrupt controller 110 has APIC interrupt providing logic 212. Rather than duplicating the APIC logic of each sequencer in the system (such as each logical processor in the SMT core or each single-threaded core), the centralized interrupt controller 110 services the interrupt for all sequencers in the system, so the APIC logic 212 single non-redundant copies are provided.

  For example, if a system (such as system 100 of FIG. 1) has four cores, each supporting eight simultaneous SMT threads, the system conventionally requires 32 copies of APIC logic 212. On the other hand, the centralized interrupt controller 110 shown in FIG. 2 utilizes a single copy of APIC logic 212 to provide interrupt controller services to all 32 active threads at a given time. .

  The APIC logic 212 may receive contention from multiple sequencers because multiple sequencers in the system may have pending interrupt operations at the same time. For this reason, the centralized interrupt controller 110 has an interrupt sequencer block 214. The interrupt sequencer block 214 sequences the services of all interrupts in the system so as to provide fair access to each sequencer of the APIC logic 212. The interrupt sequencer block 214 of the centralized interrupt controller 110 controls access to a single APIC logic block 212.

  Thus, interrupt sequencer block 214 controls sequencer access to shared APIC logic 212. This feature is in contrast to conventional APIC systems that provide a dedicated APIC logic block for each sequencer so that each sequencer has direct ad hoc access to the APIC logic. A single APIC logic block 212 may provide APIC's complete architectural requirements for interrupt prioritization, such as each processing unit of the system.

  For any processing unit in the system, the source / destination of the interrupt passing through the APIC can be another processing unit or a peripheral device. Intra-die processing unit interrupts are provided by a centralized interrupt controller 110 via the local interconnect 102. Interrupts to peripheral devices or processing units on other dies are provided via the system interconnect 106.

  FIG. 2 illustrates four message queues, input system message queue 204, input local message queue 206, output local message queue 208, and output system message queue 210, for processing input / output interrupt messages via local interconnect 102 and system interconnect 106. It has shown that. Input local message queue 206 and output local message queue 208 are connected to local interconnect 102, and input system message queue 204 and output system message queue 210 are connected to system interconnect 106. Each queue 204, 206, 208, 210 is a mini-controller queue that has data storage with control logic.

  A further description of the operation of the queues 204, 206, 208, 210 will be made with reference to FIGS. FIG. 4 provides a detailed view of at least one embodiment of the centralized APIC state 202. FIG. 4 shows that the centralized APIC state 202 has both microarchitecture states 301, 303 along with architecture state 302. As described above, the architectural state 302 maintained for each sequencer 104 (0) -104 (n) reflects the APIC state conventionally associated with the sequencer. Each entry 410 in the architecture APIC state 302 is referred to herein as an “APIC instance”. For example, an APIC instance input interrupt message may be stored in the entry 410 of the architecture APIC state 302 for the instance. For at least one embodiment, up to 240 input interrupt messages may be maintained in entry 410 of the APIC instance.

  In addition to the architecture state 302, the centralized APIC state 202 may have a microarchitecture state 301 for each APIC instance 410 along with a general microarchitecture state 303. The general microarchitecture state 303 determines which sequencer the interrupt sequencer block 214 (see FIG. 2) needs to access the APIC logic 212 (see FIG. 2). You may have a scoreboard 304 to help. In at least one embodiment, scoreboard 304 may maintain a bit for each sequencer in the system. The value of the sequencer bit may indicate whether the sequencer has any pending action required by the APIC logic 212. In at least one embodiment, the scoreboard 304 is atomically enabled so that the interrupt sequencer block 214 (FIG. 2) can easily and quickly determine which sequencer needs the APIC logic 212's attention. May be read.

  One feature of the interrupt sequencer block 214 is that it allows fair access to the APIC logic 212, but the scoreboard 304 is a sequencer that does not require the interrupt sequencer block 214 to process the APIC logic 212 simultaneously. Allows fairness schemes to be used without requiring processing resources to be wasted. Thus, the scoreboard tracks which APIC instances have work to perform based on the input message and the current state of processing of the issued request. The interrupt sequencer block 214 reads the current state from the centralized APIC state 202 for the active APIC instance and records the current state (as recorded in both the architectural state 302 and the microarchitecture state 301 of the APIC instance 410). Then take the appropriate action and then repeat the process for the next APIC instance with pending work (as indicated by the bits on the scoreboard 304).

  When an input interrupt message is submitted to another sequencer on the same die via the local interconnect 102, the input local message queue 206 receives this message and determines its destination. The interrupt message can be targeted to one, many or all of the sequencers, or none of them. The queue 206 may write to each sequencer's architecture state entry (such as 410 in FIG. 4) to queue up the interrupt. In such a case, if the scoreboard entry has not already been set to indicate that the interrupt action is pending and the service of the single APIC logic block 212 is required for the target sequencer, the queue 206 will also Set the scoreboard entry for the target sequencer.

  However, FIG. 4 shows that some interrupts may be bypassed directly from the input local message queue 206 to the output queues 208, 210 without being queued up in the centralized APIC state 202. . This may occur, for example, for broadcast messages that are not specifically addressed to a particular processor. FIG. 4 shows that a similar bypass process is also performed from the input system message queue 204 (described below).

  A process similar to that described above for queue 206 is also provided by one of the sequencers 104 (0) -104 (n) where the input interrupt message is routed via system interconnect 106 (from an I / O device or sequencer on another die). May be performed when the target is thrown. The input system message queue 204 receives a message and determines the destination of the message. The queue 206 writes up to the architecture state entry 410 of each targeted sequencer to queue up the interrupt and update the scoreboard entry 412 of any targeted sequencer. Of course, the input message may be bypassed as described above.

  One or more of the message queues 204, 206, 208, 210 may implement an input / output message firewall function. With respect to this firewall function, FIG. 2 is described together with FIG.

  For input messages, the input system message queue 204 may function as an interrupt firewall to avoid unnecessary processing of messages that are not targeted to the sequencer on the die 150 associated with the centralized interrupt controller 110. As shown in FIG. 1, the system 100 may have multiple multi-sequencer dies 150 (0) -150 (n). Interrupts generated by a particular die sequencer may be sent to other dies over the system interconnect 106. Similarly, interrupts generated by peripheral device 114 may be sent to the die via system interconnect 106.

  The centralized interrupt controller 110 (and input system message queue 204) of the die 150 determines whether the destination address of such a message has any sequencer (such as a core or logical processor) on the die 150. Might do. If the message is not intended for any core or logical processor on the local interconnect 102 associated with the die, the input system message queue 204 refuses to forward the message to any of the sequencers on the local interconnect 102. In this way, the input system message queue simply determines that no action is required, thus avoiding the “waking” of the core / thread. This saves power and saves local interconnect 102 bandwidth. This is because it eliminates the need for each sequencer to wake up from the power saving state just to determine that the message is not intended for them.

  Even if one or more logical processors are not in a power saving state, the input system message queue 204 is currently executing by the logical processor to simply determine that the input interrupt message requires no action on their part. The firewall function may still be performed so as not to interrupt the logical processor from the work.

  For at least one embodiment, a firewall may also be implemented for outgoing messages. This may be true for output local messages as well as output system messages for at least one embodiment. For at least one embodiment, the local message firewall configuration does not require that each message on the local interconnect 102 be delivered to all sequencers, but the targeted interrupt message is provided to a particular sequencer. It is implemented only for systems having a local interconnect 102 that supports a configuration that enables this. In such a case, the output local message queue 208 may send each interrupt message as a unicast or multicast message via the local interconnect 102 only to the sequencer targeted by the message. Thus, sequencers that are not targeted do not need to interrupt their processing to determine that their actions are not required in the interrupt message. Output system messages may be targeted as well so that they are not unnecessarily sent to untargeted entities.

  FIG. 2 illustrates that after an input interrupt message is placed in the APIC state 202 centralized by the input message queues 204, 206, the interrupt sequencer block 214 performs APIC processing of the system to execute the APIC logic 212 (FIG. 2). Indicates that it may provide fair access between each sequencer in the system to one copy of (see). The interrupt sequencer block 214 may actually implement this fairness scheme by sequentially traversing the APIC state 202 and providing access to the next sequence of APIC logic 212 attempting to pull it. Absent. The fairness scheme implemented by interrupt sequencer block 214 may allow each sequencer to have equal access to the interrupt providing block.

  For at least one embodiment, the conceptual sequential stepping via the APIC state 202 entry is made more efficient by utilizing a scoreboard (see 304 in FIG. 4). May be queried atomically to determine which active sequencer next needs the APIC service. For at least one embodiment, sequential access can be controlled according to the method described in more detail below in connection with FIG.

  FIG. 5 illustrates an interrupt sequencer block 214 (to provide equitable access to each sequencer of the system to one copy of APIC logic 212 (see FIG. 2) to perform the APIC processing of the system. FIG. 3 is a state diagram illustrating a method 500 utilized by at least one embodiment of (see FIG. 2). The following description of FIG. 5 is made with reference to FIGS.

  Overall, FIG. 5 shows that the interrupt sequencer block 214 reads the current state from the centralized APIC state 2020 of the active APIC instance, takes action appropriate to the current state, and has the next APIC instance with pending work. Indicates that the process is repeated.

  FIG. 5 shows that the method 500 starts at state 502. In state 502, interrupt sequencer block 214 queries scoreboard 304 to determine which APIC instances have work to perform. As described above, there may be one entry 412 in the scoreboard 304 for each APIC instance. The entry 412 may be a 1-bit entry in at least one embodiment. Bit 412 may be set when an incoming message is written to the centralized APIC state 202 of the APIC instance.

  Of course, those skilled in the art will recognize that the scoreboard 304 is a performance enhancement that need not be present in all embodiments. For at least one other embodiment, for example, the interrupt sequencer block 214 may query each entry in the centralized APIC state 202 in order (eg, sequential) to determine which active APIC instance requires service. May traverse.

  If none of the scoreboard 304 bits are set, then no sequencer has a pending APIC event. In such a case, method 500 transitions from state 502 to 508. In state 508, the method 500 may power down at least a portion of the APIC logic block 212 to power save while the logic 212 is not required. Once power down is complete, method 500 transitions to state 502 to determine if a new APIC operation is detected.

  In state 502, if no new action is detected (ie, no entry in scoreboard 304 has been set) and APIC logic 212 has already been powered down, method 500 waits for a new APIC action. Therefore, the state 502 may be changed to the state 506.

  During the wait state 506, the method 500 may periodically evaluate the content of the scoreboard 304 to determine which APIC instance has acquired pending APIC work. An input APIC message as reflected in the content of the scoreboard 304 causes a transition from state 506 to 502. The above description of the input local message queue 204 and the input system message queue 206 indicates that the architecture APIC state 302 and, at least in some embodiments, that an entry in the scoreboard 304 has acquired the APIC work pending. Explain how it is updated to reflect.

  Method 500 may determine in state 502 that at least one APIC instance has pending APIC work to perform if any entry 412 of scoreboard 304 is set. If a plurality of such entries are set, the interrupt sequencer block 214 determines which APIC instance will receive the service next by the APIC logic 212. In at least one embodiment, interrupt sequencer block 214 performs the determination by selecting the next set scoreboard entry. In this manner, interrupt sequencer block 214 imposes a fairness scheme by sequentially selecting the next active APIC instance for access to APIC logic 212.

  Upon selecting an APIC instance in state 502, method 500 transitions from block 502 to 504. At block 504, the interrupt sequencer block 214 reads the selected virtual APIC entry 410 from the centralized APIC state 302. Thus, interrupt sequencer block 214 determines which APIC events are pending for the selected APIC instance. Multiple APIC events may be pending and may be reflected in APIC entry 410. During each iteration of state 504, only one pending event is processed for the APIC instance. Thus, a round robin type sequential fairness scheme may be maintained.

  In order to select from multiple pending interrupt events for the same active APIC instance, interrupt sequencer block 214 performs prioritization in state 504. Such prioritization processing may emulate a prioritization scheme performed by a dedicated APIC of a conventional system. For example, APIC interrupts are defined to fall into each class of importance. The architecture state entry 410 (FIG. 4) for each APIC instance may hold up to 240 pending interrupts per logical processor in at least one embodiment. These can belong to 16 importance classes and fall into 16 prioritized groups. Class 16-31 interrupts have higher priority than classes 32-47. The lower the interrupt class number, the higher the interrupt priority. Thus, the interrupt sequencer block 214 observes 240 bits of the APIC instance and, if multiple, sets only one event in the state 504 (based on APIC's existing architecture priority rules). In at least one embodiment, interrupt sequencer block 214 calls APIC logic 212 to perform this prioritization.

  Thereafter, the method 500 schedules or performs actions appropriate for the selected event in state 504. For example, this event may be waiting for an acknowledgment for an interrupt message previously sent from one of the output message queues. Alternatively, the event may be that an output interrupt message needs to be sent. Or, for one of the sequencers, an input interrupt message or acknowledgment may need to be serviced. Interrupt sequencer block 214 may activate APIC logic 212 to service the event in state 504.

  If an acknowledgment is waiting, interrupt sequencer block 214 queries microarchitecture state 303 to determine that such an acknowledgment is waiting. If so, interrupt sequencer block 214 queries the appropriate entry in APIC state 202 to determine if an acknowledgment was received in state 504. Otherwise, exit from state 504 to process the next sequencer event.

  If an acknowledgment is received, the microarchitecture state 303 is updated to reflect that the acknowledgment is no longer waiting. The interrupt sequencer block 214 may also clear the APIC instance scoreboard 304 entry before returning to state 502. In at least one embodiment, the scoreboard entry 304 is cleared only if the currently serviced event is only the pending event for the APIC instance.

  In another example, if the event serviced in state 504 is a transmission of an interrupt message (via the local interconnect 102 or system interconnect 106), such event is serviced in state 504 as follows. The interrupt sequencer block 214 determines which output messages need to be provided from the APIC instance of the currently serviced logical processor given the above priority processing. The output message is then scheduled for transmission to the appropriate output message queue (output local message queue 208 or output system message queue 210) along with the desired destination address.

  If the outgoing message requires additional services, such as receipt of an acknowledgment, before the event is fully serviced, the centralized controller 110 indicates that additional services are required for the event. Therefore, the microarchitecture state 303 may be updated. (Input acknowledgments via the local interconnect 102 or the system interconnect 106 are queued up in the input message queues 204, 206 so that they can eventually be processed in the next iteration of the associated APIC instance state 504. , May be updated to the centralized APIC state 202. The method then transitions from state 504 to 502.

  FIG. 6 illustrates at least one embodiment of a multi-threaded computing system 900 capable of performing the disclosed techniques. The computing system 900 includes at least one processor core 904 (0) and a memory system 940. System 900 may have additional cores (˜904 (n)) as indicated by dashed lines and ellipses.

  Memory system 940 may have a large, relatively slow memory storage 902 with one or more small, relatively fast caches such as instruction cache 944 and / or data cache 942. Memory storage 902 may store instructions 910 and data 912 for controlling the operation of processor 904.

  The memory system 940 is intended as a generalized representation of memory, such as hard drives, CD-ROMs, RAM (Random Access Memory), DRAM (Dynamic RAM), SRAM (Static RAM), flash memory and related circuitry May have various forms of memory. Memory system 940 may store instructions 910 and / or data 912 represented by data signals executable by processor 904. The instructions 910 and / or data 912 may include code and / or data for performing any or all of the techniques described herein.

  FIG. 6 shows that each processor 904 is connected to a centralized interrupt controller 110. Each processor 904 may have a front end 920 that provides instruction information to the execution core 930. The fetched instruction information may be buffered in the cache 225 to wait for execution by the execution core 930. The front end 920 may provide instruction information to the execution core 930 in program order. In at least one embodiment, front end 920 includes a fetch / decode unit 322 that determines the next instruction to be executed. In at least one embodiment of the system 900, the fetch / decode unit 322 may have a single next instruction pointer fetch logic 320. However, in embodiments where each processor 904 supports multiple thread contexts, the fetch / decode unit 322 implements different next instruction pointer fetch logic 320 for each supported thread context. The optional nature of additional next instruction pointer fetch logic 320 in a multiprocessor environment is illustrated by the dashed lines in FIG.

  Each embodiment of the method described herein may be implemented by hardware, hardware emulation software or other software, firmware, or a combination of such implementation approaches. Embodiments of the present invention can be implemented for a programmable system having at least one processor, a data storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device. It is. For this application, a processing system includes any system having a processor such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

  The program may be a storage medium or device readable by a general purpose or special purpose programmable processing system (hard disk drive, floppy disk drive, ROM (Read Only Memory), CD-ROM device, flash memory device, DVD ( (Digital Versatile Disk) or other storage device). The instructions accessible to the processor of the processing system configure and execute the processing system when the storage medium or device is read by the processing system to perform the procedures described herein. Each embodiment of the present invention is also considered to be implemented as a machine-readable storage medium configured for use by a processing system, and the storage medium configured as such provides the functionality described herein to the processing system. It is executed by a specific and predetermined method for execution.

  The exemplary system 900 is available from Intel Corporation, although other systems (including other microprocessors, engineering workstations, personal digital assistants, other portable devices, set-top boxes, etc.) are also available. Pentium (R), Pentium (R) Pro, Pentium (R) II, Pentium (R) III, Pentium (R) 4, Itanium (R), Itanium (R) 2 Microprocessor, Mobile It represents a processing system based on Intel (R) Pentium (R) III Processor-M, Mobile Intel (R) Pentium (R) 4 Processor-M. In one embodiment, the example system may run a version of the Windows operating system available from Microsoft Corporation, although other operating systems and graphical user interfaces may also be available.

  While particular embodiments of the present invention have been illustrated and described, it would be obvious to those skilled in the art that various changes and modifications can be made without departing from the scope of the appended claims. For example, at least one embodiment of the centralized APIC state 202 may include only a single read port and a single write port. In such an embodiment, input system message queue 204, input local message queue 206, and interrupt sequencer block 214 utilize arbitration logic (not shown) to gain access to centralized APIC state 202. It may be.

  Also, for example, at least one embodiment of the method 500 shown in FIG. Those skilled in the art will recognize that state 508 only provides performance enhancement (power saving) and is not required for the claimed invention embodiments.

  It has also been mentioned above that, for example, at least one embodiment of the centralized interrupt controller 110 described above may eliminate the scoreboard 304. In such an embodiment, interrupt sequencer 214 may sequentially traverse entry 410 in architecture APIC state 302 to determine the next APIC instance to receive service from APIC logic 212.

  Thus, those skilled in the art will recognize that various changes and modifications can be made in the broadest aspects thereof without departing from the invention. The appended claims are intended to include within their scope all such changes and modifications as fall within the true scope of the present invention.

100 system 104 core 110 interrupt controller 359 multi-core threading environment

Claims (24)

A single logic block that performs priority and control functions for providing interrupt messages to a plurality of processing units and is shared by the plurality of processing units;
An interrupt sequencer block connected to the logic block for scheduling interrupt events of the plurality of processing units for processing by the logic block;
A storage area that maintains architecture interrupt status information for each of the plurality of processing units;
One or more input message queues that receive an input interrupt message and place information from the message in the storage area;
One or more output message queues for sending output interrupt messages;
Having a device.   The apparatus of claim 1, wherein the single logic block has non-redundant circuitry rather than redundant logic for each processing unit.   The apparatus of claim 1, wherein the interrupt sequencer block schedules interrupt events for the plurality of processing units according to a fairness scheme.   4. The apparatus of claim 3, wherein the interrupt sequencer block schedules interrupt events of the plurality of processing units according to a sequential traversal of the storage area.   The apparatus of claim 1, further comprising a scoreboard for maintaining data regarding which of the processing units have pending interrupt events.   The apparatus of claim 1, wherein the storage area further stores microarchitecture state information.   The apparatus of claim 1, wherein the plurality of processors communicate over a local interconnect. The one or more input message queues include a message queue for receiving an input interrupt message via the local interconnect;
The apparatus of claim 7, wherein the one or more output message queues comprise a message queue for sending output interrupt messages over the local interconnect. The one or more input message queues include a message queue for receiving an input interrupt message via a system interconnect;
The apparatus of claim 7, wherein the one or more output message queues comprise a message queue for transmitting output interrupt messages over the system interconnect.   The apparatus of claim 1, wherein the one or more output message queues further extract information about the output interrupt message from the storage area.   The apparatus of claim 1, wherein the one or more output message queues further comprise firewall logic for prohibiting one or more transmissions of the output interrupt message.   The apparatus of claim 1, wherein the one or more input message queues further comprise firewall logic for prohibiting one or more transmissions of the input interrupt message to one or more of the processing units. Querying the storage array to determine one architecture interrupt state of the plurality of processing units;
Scheduling one of the processing units for an interrupt providing service of a non-redundant interrupt providing block;
A method comprising:
The scheduling is performed according to a fairness scheme that allows each processing unit to have equal access to the interrupt providing block.   The method of claim 13, wherein the interrupt providing block comprises advanced programmable interrupt controller logic.   The method of claim 13, wherein the fairness scheme is a sequential round robin scheme for the processing unit having one or more pending interrupt events. A plurality of processing units executing one or more threads;
A memory connected to the processing unit;
A shared interrupt controller that provides an interrupt providing service for the plurality of processing units;
Having a system.   The system of claim 16, wherein the shared interrupt controller further provides an APIC interrupt providing service for the plurality of processing units.   The system of claim 16, wherein the processing unit does not have self-contained APIC interrupt providing logic.   The system of claim 16, wherein the shared interrupt controller further comprises firewall logic.   The system of claim 16, further comprising a local interconnect connected to the plurality of processing units.   21. The system of claim 20, wherein the shared interrupt controller further comprises firewall logic that prohibits transmission of one or more interrupt messages over the local interconnect.   The system of claim 16, further comprising a system interconnect connected to the shared interrupt controller.   23. The system of claim 22, wherein the shared interrupt controller further comprises firewall logic that prohibits transmission of one or more interrupt messages over the system interconnect.   The system of claim 16, wherein the shared interrupt controller further schedules an interrupt serial service between the plurality of processing units.

Images