CS 452/652 Spring 2022 - Lecture 10

Interrupt Confirmation

• cause for interrupt (at device):
  • event, such as timer underflow → edge trigger
    • device will not trigger interrupt again unless previous one confirmed
  • status, such as buffer empty → level trigger
    • after completion of interrupt handler, interrupt would trigger again!
      → force status change or disable interrupt
• example: confirm timer interrupt by writing to BASE + 0x0C.

Timer Interrupt

• device automatically generates interrupt, if timer is enabled
• timer underflow: interrupt when timer reaches 0 (timer continues and/or is reloaded)
• VIC must enable/disable/configure interrupt delivery
• CPU must accept interrupts (user mode)
• generic interrupt handler

    query VIC status register for interrupt source
    choose and process interrupt
    make current task ready
    schedule next task
  

• confirm interrupt before/during/after processing

Interrupt Processing

• central interrupt processing

  query VIC status
  process interrupt
  confirm/disable interrupt
  

  one shot, then schedule – 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 simpler
• one shot processing seems safe bet

AwaitEvent

• 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?
  • excessive 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

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

Server Processing

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

Clock Notifier

• main loop (at high priority)

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

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 (;;) {
    while (maintenance()) yield();
    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...