Interrupts

Question 1

Who generates External/Asynchronous interrupts?

Answer 1

Triggered by devices external to the core’s compute circuitry
• “Asynchronous” because they can occur at any time
• (“between CPU operations”)

Question 2

Who generates Internal/synchronous interrupts?

Answer 2

Triggered by the core’s compute circuitry (CPU instructions)
– Well, actually, it’s the software that runs on the core…
– Which is why such interrupts are also sometimes called
» “Software interrupts”
• (“while a CPU operation occurs”)

Question 3

How interrupts handled in x86/linux?

Answer 3

Each interrupt is associated with a

– Number (called “interrupt vector”)
• There are 256 interrupt vectors, numbered 0…255

– Handling routine (called “interrupt handler”)

Question 4

When the interrupt handler array is set up?

Answer 4

Array content is initially set by BIOS
• (For example, to be able to use keyboard before OS is up)
– Later, at boot time, array is reinitiated by OS with its own routines

Question 5

What’s the routine for interrupt handling?

Answer 5

The interrupt handler
– Save state of currently running process P
– Execute handler
– Return to user mode, resuming either P or another process

Question 6

What are the two interrupt handling contexts? (synchronous and asynchronous )

Answer 6

If asynchronous interrupts, kernel is said to be in “interrupt context”
• It doesn’t directly serve the process that has just been stopped

– If synchronous, kernel is in “process context”
• It needs to provide some service to the process that invoked it
(whether explicitly or implicitly)

Question 7

Are interrupts a schedulable entity?

Answer 7

No. interrupts are handled at the moment they are fired, even if what’s currently running is “more important”.

Question 8

What happens to masked interrupts?

Answer 8

If interrupt vector K should fire but is masked

x86 HW remembers at most 2 instances of K (the rest get lost, if exist)

Question 9

Handling an interrupt might take a long time
But we want to allow OS to decide if it has more important stuff to do.
What can we do?

Answer 9

Solution: split the handler into two:
– Fast/Hard/First‐Level Interrupt handler (FLIH)
• What we must do when receiving an interrupt, and nothing else
• Not interruptible => as small and as quick as possible

– Slow/Soft/Second‐Level interrupt handler(SLIH)
• All the rest (lower priority)
• Interruptible; will be executed later by some kernel thread

Question 10

Give an example of top half and bottom half splitting of an interrupt.

Answer 10

When receiving a packet from the network.

Possible top half
(not schedulable, occurs immediately)
• Put a pointer to the received packet in a queue for later processing
• Give the NIC (network card) a new free memory buffer, such that it will have room
to save subsequent incoming packets

Possible bottom half
(will happen later when the scheduler decides)
• Hand packet to network stack
• Copy the content of the packet to the memory space of the
corresponding user application
• Notify the user app that a new packet has arrived

Question 11

Resume an interrupted process - where?

Answer 11

If asynchronous interrupt (external) or system call (synchronous=internal, explicit)
then in the next process instruction, Right after the last instruction that was executed.

If exception (synchronous=internal, implicit)
– Resume in the same instruction that the HW failed to execute
- and send a signal (in case we e.g. divided by 0, no sense in executing the same command).

Question 12

Interrupt handling in multicores – where?

Answer 12

Internal=synchronous interrupts (system call, divide by 0, …)
– Each core handles on its own

External=async interrupts (generated by external devices)
– Can do static partition of interrupts between cores
• E.g., all interrupts go to core 0
• Or, all interrupts in range x–y go to core j
– Can do dynamic partition of interrupts between cores
• E.g., round robin
• Or, send interrupt to least loaded core

Question 13

What’s polling?

Answer 13

Polling is an alternative to interrupt-based processing
– OS turns off interrupts and instead polls the NIC every once in a while
– Effective when OS is mostly busy handling the packets
(used when OS is overwhelmed by interrupts).

Question 14

What are the cons of polling?

Answer 14

1. Polling too frequently might waste CPU cycles if not enough packets
2. Polling too infrequently increases latency & may result in packet loss

Question 15

What’s Interrupt coalescing?

Answer 15

When the HW joins several interrupts of the same type in order to not overwhelm the OS.
Or by SW if it detects an interrupt storm.