CS 452/652 Fall 2019 - Lecture 13

October 2, 2019 prev next

AwaitEvent / Interrupt Handling

task(s) waiting for interrupt to occur: store one or queue? → design decision
interrupt without waiting task: store one or several?
- execssive buffering is not helpful in any producer/consumer scenario
- multiple same interrupts without waiting task indicate performance problem!
- use task prioritity to make sure that hardware interrupts are handled promptly
AwaitEvent() argument and return code → design decision
central interrupt processing
```
query VIC status
process interrupt
confirm interrupt
```
one shot, then leave kernel – or loop of interrupt processing?
- one shot works, because next interrupt would be taken right before the first user instruction is being executed
- loop should work, if VIC status is updated during kernel processing? probably...
- are multiple/repeated interrupts pending?
  - yes/often → loop more efficient
  - no/rarely → one-shot more efficient
one shot processing seems safe bet

Clock Server

main loop of receiving and processing requests
server never blocks ⇒ cannot call AwaitEvent()
task blocking delegated to clock notifier
server & notifier → general design pattern

Clock Notifier

main loop (at high priority)

loop:
  AwaitEvent()
  Send() tick to clock server

Server Processing

TICK: advance clock value and check parked tasks in timer list
TIME: reply to client with current clock value
DELAY: park client task (using tick & tid) in timer list
- two variations: absolute vs. relative tick
timer list should probably be a sorted data structure

Kernel Startup

interrupts during system bootstrap

VIC initialization
timer initialization
create first user task

for (;;) { // kernel main loop
  currtask = schedule();
  request = activate(currtask);
  handle(request);
}

timer interrupt might be raised, before the first instruction of the first user task is executed
be aware and handle this case (as simply as possible)!

Idle/Halt

what to do when processor has not other work?
- SETI? cryptomining? → often not appropriate!
- maintenance, e.g., garbage collection → not relevant for CS 452 kernel
- diagnosis, such as computation of idle fraction
- save energy → halt! (cf. "race-to-idle/sleep")
implement as dedicated idle task at lowest priority
```
for (;;) {
  diagnosis();
  park();
}
```
ARMv4T has no dedicated instruction for 'park'
EP 9302 provides device register to gate CPU clock (Section 5.2 in EP93xx User Guide)
- read from 0x80930008 triggers halt
- next IRQ wakes up CPU again
alternative: write to co-processor register (Section B6.6.5 in ARM Architecure Reference Manual)
- might not be working; system hangs...?