CS 452/652 Fall 2019 - Lecture 11

Interrupts

Basics

• motivation: avoid overhead from continuous polling
• hardware delivers asynchronous notifications
  • kernel potentially notifies task(s)
• interrupt handling also present overheads
  • direct: pipeline flush, handler execution
  • indirect: cache disturbance (CPU, TLB, branch predictors)
• high-rate of interrupts? use hybrid approach:
  • poll device and deliver event
  • only enable interrupt, if poll (or several polls) unsuccessful
  • disable interrupt after it is triggered
  • real-world example: Linux NAPI
• not strictly necessary for CS 452 kernel

Case Study: Working with Imperfect Information

• interrupt processing with respect to the ARM 920T pipeline?
• difficult to find direct information in ARM manuals
  • we know: interrupts logically arrive in between any two instructions
  • online search: ARM 920T has 5 pipeline stages: fetch, decode, execute, memory, write
  • ARM documentation: return from interrupt handler should branch to lr-4.
• conclusion: when interrupt is taken at clock tick,
  • instructions beyond 'fetch' stage are finished,
  • the just fetched instruction is discarded, but
  • pc points to next instruction, therefore
  • the discarded instruction at pc-4 needs to be re-issued after return from IRQ handler.

Fast Interrupts

• other kernels execute interrupt handlers and return to current task
• FIQ mode in ARM provides several banked registers
  • this permits simple processing without much state saving
  • and quick return to interrupted task
• not relevant for CS 452 kernel, since each interrupt preempts and reschedules current task

Coding

• handler.S - using assembler macros (similar to C preprocessor) to code uniform routine for swi- or irq-based kernel entry.

Race

• concurrent or parallel access to shared resource - at least one write
• results in non-deterministic outcome
• coordination to avoid races has overhead
• not all races are problematic! but:
  • correctness problem, if at least of the possible outcomes is incorrect
  • repeatability problem, especially with program modifications (debugging)
• data races very prevalent for multi-cpu computing
  • careful approach to coordination needed to attain highest performance
• non-determinism in CS 452
  • track and trains → sensor reports
  • human operator
• races in CS 452
  • could arise during interrupt handler when accessing shared data
  • however
    • kernel (and interrupt handler) is not interrupted
    • only user tasks are interrupted
    • user tasks do not share data with each other
  • but be aware of the potential problem!