Re: MSI interrupts

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