Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: MSI interrupts Date: Wed, 19 Mar 2025 19:17:31 +0000 Organization: Rocksolid Light Message-ID: References: <53b8227eba214e0340cad309241af7b5@www.novabbs.org> <3pXAP.584096$FVcd.26370@fx10.iad> <795b541375e3e0f53e2c76a55ffe3f20@www.novabbs.org> <1681197d3c1af131d6b8cae884f7c9ca@www.novabbs.org> <8BVBP.816276$eNx6.247046@fx14.iad> <20250317161132.00004dd9@yahoo.com> <1WZBP.558392$SZca.243157@fx13.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="894331"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Site: $2y$10$92O5o9nn2khfqfbOrMd6I.9wII4U8Iu2blVN6sMFpam85BBXXNGMe Bytes: 4206 Lines: 61 On Wed, 19 Mar 2025 17:27:46 +0000, Robert Finch wrote: > On 2025-03-19 12:00 p.m., MitchAlsup1 wrote: >> On Wed, 19 Mar 2025 15:20:20 +0000, Stefan Monnier wrote: >> >>> MitchAlsup1 [2025-03-17 21:49:18] wrote: >>>> On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote: >>>>> Method 1 is simplest, it injects the interrupt request at Retire >>>>> as that's where the state of everything is synchronized. >>> [...] >>>> Lowest interrupt Latency >>>> Highest waste of power (i.e., work) >>>> >>>>> Method 2 pipelines the switch by injecting the interrupt request at >>>>> Fetch. >>> [...] >>>> Interrupt latency is dependent on executing instructions, >>>> Lowest waste of power >>> >>> What do existing CPUs do? >> >> Lean in the direction of method 2 will fallback position of method 1 >> if anything goes wrong. >> >>> Method 2 looks insanely messy, so I'd assume method 1 is the standard >>> approach, right? >> >> It is "not that bad" on the large scale of things. >> > Undaunted he tries to implement the method 2 approach using an IRQ > victim queue for IRQs that should not be processed at retire. It is not > too bad to code, but I dunno if it works yet. Just a switch at fetch > time to select from the victim queue first, otherwise pop the normal IRQ > queue. The queue is small, assuming that IRQs are not disabled for great > lengths of time. Interrupt table MSI-X message undergoes negotiation. One possible result of interrupt negotiation is that core can reject said interrupt, and message is returned to the interrupt table. During this time, core is not doing anything but running its previously assigned thread. The negotiation takes place in state machines more optimally positioned for throughput and latency than the function units within cores. So, core has not done anything speculative wrt IROing except that which has a well developed protocol. Now, once core claims the interrupt, it performs as if it were the typical von Neumann "perform 1 instructions then move on" Mantra enforced by boatloads of reservations stations and predictors and prediction repair mechanisms. Accessing memory with side effects is not one of those mechanisms and must be ordered properly wrt {interrupts, exceptions, mispredictions, and program order}. But on the scale of a FDIV unit that sends out a 0.51 ULP result on cycle 12 and can send out the 0.500 ULP result on cycle 17, and fixing the intermediate damage--handing off to an interrupt handler is "not that bad". >>> >>>         Stefan