3 ms·

Because you say kernel, I'm assuming you mean ability to switch a set of registers instead of pushing them on the stack when servicing an interrupt request. Un

by vardump 10y ago

Because you say kernel, I'm assuming you mean ability to switch a set of registers instead of pushing them on the stack when servicing an interrupt request. Unfortunately you can't get away with just one set of spare registers on x86 interrupt handling. Interrupt can be interrupted by another interrupt. So practically they have to save registers anyways. Unless there'd be one set for each level... So those "10 extra registers" would be practically useless. Having written kernel device driver interrupt handlers, I can also say CPU time is not spent saving and restoring registers, but waiting for glacially slow PCI-e MMIO register loads and stores (don't have exact figures at hand, but I remember one access can take 300-800 nanoseconds, that's thousands of CPU clock cycles). During one such fetch you might be able to store and restore registers tens, if not hundreds of times. X86 interrupt handling is a bit like stopping a freight train to pick up a single letter. However, that kind of feature can be very useful on a microcontroller to help lowering interrupt handling latency.

Dylan16807 10y ago
> Interrupt can be interrupted by another interrupt. So practically they have to save registers anyways. Only when an interrupt actually does get interrupted. You could make the common case faster. Not that it matters if PCI-e is the bottleneck.
- vardump 10y ago
  Then all interrupts need to be prepared for it and check for it anyways. Crucially, the code path that does the check might also get interrupted, even multiple times. No synchronization is possible, and even if it was, it'd be slower than simply saving the registers. So what do you suggest could be done?
  - Dylan16807 10y ago
    It doesn't matter if that code path gets interrupted. There's no need to synchronize anything. If interrupt A sees that the extra registers are idle, and then gets interrupted, that's okay. By the time the inner interrupt returns, even if the inner interrupt used them, they will be put back to idle, and A can safely switch to them. Everything else works the same as current hardware. There's the cost of a branch, but you could remove that by making it a hardware feature. It's a branch that should predict well though.
CyberDildonics 10y ago
Isn't a cache miss around 100 nanoseconds? This sounds like memory latency without all the out of order execution and other modern CPU features.
- vardump 10y ago
  Nothing to do with (local) DRAM, everything to do with PCI-e bus. Reading and writing to memory mapped I/O registers is how you send commands to peripherals, read their status, etc. These registers are not really memory at all, but representation on various logic states on the peripheral. So what you write is often not what you read back. Note that I/O memory mapping has nothing to do with usermode memory mapping.

by vardump 10y ago

Dylan16807 10y ago

> Interrupt can be interrupted by another interrupt. So practically they have to save registers anyways. Only when an interrupt actually does get interrupted. You could make the common case faster. Not that it matters if PCI-e is the bottleneck.

vardump 10y ago
Then all interrupts need to be prepared for it and check for it anyways. Crucially, the code path that does the check might also get interrupted, even multiple times. No synchronization is possible, and even if it was, it'd be slower than simply saving the registers. So what do you suggest could be done?
- Dylan16807 10y ago
  It doesn't matter if that code path gets interrupted. There's no need to synchronize anything. If interrupt A sees that the extra registers are idle, and then gets interrupted, that's okay. By the time the inner interrupt returns, even if the inner interrupt used them, they will be put back to idle, and A can safely switch to them. Everything else works the same as current hardware. There's the cost of a branch, but you could remove that by making it a hardware feature. It's a branch that should predict well though.

CyberDildonics 10y ago

Isn't a cache miss around 100 nanoseconds? This sounds like memory latency without all the out of order execution and other modern CPU features.

vardump 10y ago
Nothing to do with (local) DRAM, everything to do with PCI-e bus. Reading and writing to memory mapped I/O registers is how you send commands to peripherals, read their status, etc. These registers are not really memory at all, but representation on various logic states on the peripheral. So what you write is often not what you read back. Note that I/O memory mapping has nothing to do with usermode memory mapping.