OSDev.org

I love the simplicity of interrupts present in DOS... much easier for me to understand than calling to a dynamic library... So I thought, why not have interrupts for libraries?
I have heard a lot about how interrupts are kind of slow when communicating between the kernel and the user level, but what about same ring interrupts? Is there any slow down compared to a "call" ?

Thank you,
Veniamin

An interrupt does significantly more than a simple call. That and you have a rather limited amount of interrupts to use.

Indeed interrupts do a bit more than a call. I'll probably be trying to use as many features from interrupts as I could, if I do use them. But what I ask is if there is still a significant slow down if using interrupts of the same ring level.

Hi,

CPLH wrote:Indeed interrupts do a bit more than a call. I'll probably be trying to use as many features from interrupts as I could, if I do use them. But what I ask is if there is still a significant slow down if using interrupts of the same ring level.

For an interrupt to the same privilege level, the CPU still needs to lookup an entry in the IDT and interpret it (do validity/protection checks, etc), then lookup an entry in the GDT and interpret that (do more validity/protection checks, etc), then push return values on the stack and set a new CS:EIP. If the IDT entry and GDT entry aren't in cache anymore then the CPU needs to fetch 2 extra cache lines from RAM; and because of the validity/protection checks the CPU can't easily use it's branch prediction to speed things up either.

I'd estimate that a software interrupt to the same privilege level could cost between about 20 cycles (everything cached) and more than 100 cycles (nothing cached), and would be around 10 times slower than an indirect call. This is just my estimate though - you could check with RDTSC on a variety of CPUs/computers to get a more accurate estimate.

Combuster's right about the limited number of interrupts too. There's only 256 entries in the IDT. 32 are reserved for exceptions and IRQs take at least 16 more of them - for a fully loaded server with PCI devices using "message signalled interrupts" and/or large I/O APIC/s you could easily need 128 or more interrupts just for IRQs. Then you might need one for each I/O APIC's spurious interrupt, some for local APIC interrupts (local APIC timer, performance monitoring, thermal status, etc), one for the kernel's own API, some for IPIs, etc. Worst case you may have less than 64 IDT entries left over, and they'll be scattered throughout the IDT (not sequential) due to the way APICs do interrupt priorities.

I'd also be worried about multi-tasking, multi-CPU and task switch times (e.g. a different IDT for each CPU, where the CPU's IDT is changed dynamically during task switches because different tasks used different libraries), but I'm not sure if this matters for your OS though (your OS could be "single-tasking single-CPU only").


Cheers,

Brendan