← Back to context

Comment by amluto

8 hours ago

You can do this on x86 as well at a cost a merely tens to hundreds (possibly lots of hundreds) of thousands of cycles. This is part of why x86 is so popular in the embedded space.

(I’m being sarcastic, obviously. x86 interrupts and interrupt returns are hilariously slow. FRED may improve this by quite a bit.)

5 comments

amluto

Reply
vlovich123  2 hours ago

But you’re also comparing dozens of cycles at 10mhz to 100ks at 5ghz. That’s probably comparable in terms of wall clock, no?

nomel  6 hours ago

What's the technical reason for them being slow? Book keeping with caches or something?

  • monocasa  5 hours ago

    Mostly tons of speculative state that needs to be unwound, combined with spectre mitigations, plus tons of committed state that the interrupt prologue needs to save, plus a huge song and dance to do that correctly (that FRED should help with).

    All combined with the fact that there's a good chance the memory the interrupt handler is going to touch isn't in the cached working set anymore, both in the actual L* caches and in subtler places like the branch predictors and TLBs.

    • amluto  3 hours ago

      You’re missing the big ones: both the interrupt delivery and the IRET (interrupt return) mechanisms use incredibly complicated data structures to determine what the new state should be. They need to dig around in the IDT, the GDT, the TSS and possibly the LDT to find all the register values they need to set, and they need to handle all kinds of backwards compatibility. And they “serialize”, which is an extra heavyweight fence, although that only likely accounts for a few hundred cycles in each direction.

      Check out the pseudocode in the SDM — there are pages of it, and the pseudocode isn’t even complete.

      FRED simplifies the state transitions such that the new state is mostly a foregone conclusion based on MSR contents.