CS 452/652 Winter 2020 - Lecture 13

AwaitEvent / Interrupt Handling

• matchmaking: task ↔ event
• task(s) waiting for interrupt to occur: store one or queue? → design decision
• interrupt without waiting task: buffer one or several? or failure?
  • 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
  reply to clients whose waiting times have completed
• 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);
  }
  

• 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)
  • only works in privileged mode...