Single-core scheduling #

Computational resources #

  • Preemptible: Can give to a thread and can take it away
    • Network interfaces
    • Scheduling: how long thread keeps resources, who’s next
  • Non-preemptible: Can’t take away without permission
    • File space
    • Allocation: who gets what

Deciding which resources are preemptible or not is associated with the cost to preempt.

Which thread should run on which core for how long?

Goals #

  • Minimize response time (to useful result - down to human response time of 50-100ms)
  • Use resources efficiently
    • Keep resources busy if there is work to do for them
    • Minimize context switches

First-come-first-serve (FCFS/FIFO) #

  • Keep a ready queue of runnable threads
  • When a thread becomes runnable, add it to the back
  • When a core runs out of work to do (locks or exits), run first thread on queue

Disadvantage: One thread can monopolize core

Round-robin #

  • Each thread gets to run for a given time slice, then goes to the back of the queue
  • In practice: Time slices are in the range of 5-10ms (4ms in Linux)

For time slices:

  • Too large: slow response, since threads can monopolize cores
  • Too small: context switching overhead means that resources won’t be used effectively

Shortest remaining processing time (SRPT) #

  • Schedule by least remaining processing time left
    • Breaks ties with FCFS
  • Good for resource utilization
    • Imagine scenario with a CPU-bound and I/O-bound thread
    • CPU-bound thread gets low priority, I/O-bound thread gets high priority
    • CPU-bound thread runs while I/O-bound thread is blocked, once I/O-bound thread is unblocked it can run until it gets blocked again

Gives highest priority to least needy thread!

Disadvantage: must predict the future

Priority-based scheduling #

  • Idea: Every thread has a priority maintained as part of its state
  • Run the highest priority thread
    • Use round-robin to tiebreak
  • Dynamically adjust priorities to approximate SRPT

Priority queues #

  • Maintain many ready queues
    • Threads using least resources stay in highest priority queue
    • Threads using most resources stay in lowest priority queue
  • Dispatcher runs threads from highest priority occupied queue

4.4 BSD Unix scheduler #

  • Track threads’ recent CPU usage
  • Give highest priority to thread with least usage
  • No starvation: if a thread isn’t getting executed, its priority will eventually rise and be run
  • Many runnable threads: round-robin
  • Linux biases scheduling with “nice” value: higher value means that thread yields CPU cycles, lower value means that thread tries to get more CPU cycles