CS 452/652 Spring 2025 - Lecture 6

Scheduling, Optimization, Message Passing

May 22, 2025 prev next

Kernel Design

• no stack (use SP_EL0, unsafe)
• temp stack - kernel as event handler
• single stack - default here
• per-task kernel stack - preemptive time-slicing kernel
  • often with return to task after system call
  • extra benefit: lazy context-switch (even on interrupt)
    • system call: caller-saved done by compiler
    • interrupt: save only caller-saved
      • continue on per-task kernel stack: callee-saving done by compiler
    • stack switch (in kernel): save only callee-saved

Scheduling

• preemption: each kernel entry triggers re-scheduling
  but: no time slicing, no fair scheduling
• after kernel entry and corresponding processing
  • task might be blocked → track
  • task might be ready → back on ready queue
    but not both! single intrusive linkage element sufficient
• ready queue - keep simple: array of plain FIFO queues
  • no support for timeout/cancellation of blocking operations
  • no need to remove internal element from queue
  • only push to back of queue, pop from front

Compiler Optimization

• goal is complete understanding of what we are doing → enable optimization!
  • loop unrolling
  • code without side effects might be removed
  • register caching; repeated reads or writes might be removed
  • code reordering based on performance of microarchitecture
  • compiler understands data dependencies in sequential control flow
• C/C++ keyword "volatile"
  • tells compiler about unspecified side effects related to a variable or memory location
  • compiler avoids reordering around and removal of volatile accesses
  • example: memory-mapped device register

    int cloaddr = 0xFE000000 + 0x3000 + 0x04;
    volatile unsigned int* cloptr = (volatile unsigned int*)(cloaddr);
    unsigned int tval = *cloptr;
    

Runtime/Hardware Optimization

• pipelining and out-of-order execution, subject to data dependencies
• very important challenge in other areas!
• not too relevant for CS 452/652
  • using only one processor core
  • exception handling: hardware cleans up processor pipeline

Memory & Synchronization

• no shared memory → no synchronization (lock, semaphore, etc.)
  • no sharing between kernel and user tasks
  • no sharing between user tasks
• task/kernel communication via system calls
• task/task communication by passing messages
• resource synchronization: via task patterns
  • e.g. track server task mediates access to track
• device synchronization: kernel primitive AwaitEvent()

Message Passing

• synchronous communication: Send/Receive/Reply (SRR)
  • data flows when both sender and receiver are ready
  • no asynchronous buffering
• requires blocking (i.e., suspending/resuming) tasks
  • kernel needs to track blocked tasks
  • reply guaranteed without blocking
• sender state: SendWait, ReplyWait
• receiver state: ReceiveWait
• Send/Receive Scenario 1: Send first
  • T1 Send
    • receiver tid: look up receiver - not in ReceiveWait
    • sender blocks (Ready → SendWait)
      • where to store information about senders? at receiver
  • T2 Receive
    • finds sender - sanity check for SendWait
    • sender still blocked (SendWait → ReplyWait)
    • kernel copies data
    • T2 still Ready
• Send/Receive Scenario 2: Receive first
  • T1 Receive
    • no sender found
    • receiver blocks (Ready → ReceiveWait)
    • store receive-blocked tasks in kernel container? only for cleanup/housekeeping
  • T2 Send
    • receiver tid: look up receiver - in ReceiveWait
    • unblock receiver (ReceiveWait → Ready)
    • block sender (Ready → ReplyWait)
    • kernel copies data
• Reply
  • non-blocking: sender must be waiting
  • sender tid: look up sender - sanity check for ReplyWait
  • unblock sender (ReplyWait → Ready)
  • kernel copies data
• Receive from anyone
  • no upfront filtering
  • sender's tid transmitted via Send/Receive
• Receive and Reply can be decoupled
  • in time: sender parked until later reply (reordering)
  • in space: different task replies than original receiver (delegation)
• kernel provides SRR functionality
  • provide mechanisms for blocking senders and/or receivers
  • message copying for safe asynchronous operation of sender & receiver
    • direct copy from sender to receiver and vice versa
    • no message buffering in kernel
    • kernel must also set return codes appropriately
• messages: structured data
  • no conversion (marshalling) needed as in heterogeneous distributed systems
  • copied as byte (char) array
  • type-checking: verify type of message for type of task?
    • want global type field per message?

Server Pattern

• background: reasoning about latency of critical code paths - avoid/control blocking
  • design system to control latencies!
• server provides service to clients
  a) receive request
  b) process
  c) (delayed) response
  → server always available or working: never blocks
  never calls Send() or AwaitEvent()