CS 452/652 Winter 2020 - Lecture 11
January 29, 2020
prev next
Interrupts
Basics
- motivation: avoid overhead from continuous polling
- hardware delivers asynchronous notifications
- kernel potentially notifies task(s)
- interrupt handling also presents 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
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
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.
- this also explains with interrupt vector instructions (see Lecture 6) operate at pc+8.
- during 'execute' stage, pc points to two instructions later
Coding
See example in demo11. Take a look at the source assembler version or use objdump -d to look at the binary code.
- 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!