Scheduling

1
Scheduling

• 6.894 Lecture 6

2
What is Scheduling?

• An O/S often has many pending tasks.
• Threads, async callbacks, device input.
• The order may matter.
• Policy, correctness, or efficiency.
• Providing sufficient control is not easy.
• Mechanisms must allow policy to be expressed.

3
Scheduling Policy Examples

• Allocate cycles in proportion to money.
• Maintain high throughput under high load.
• Never delay high pri thread by gt 1ms.
• Maintain good interactive response.
• Can we enforce policy with the thread scheduler?

4
Pitfall Priority Inversion

• Low-priority thread X holds a lock.
• High-priority thread Y waits for the lock.
• Medium-priority thread Z pre-empts X.
• Y is indefinitely delayed despite high priority.

5
Pitfall Long Code Paths

• Large-granularity locks are convenient.
• Non-pre-emptable threads are an extreme case.
• May delay high-priority processing.

6
Pitfall Efficiency

• Efficient disk use requires unfairness.
• Shortest-seek-first vs FIFO.
• Read-ahead vs data needed now.
• Efficient paging policy creates delays.
• O/S may swap out my idle Emacs to free memory.
• What happens when I type a key?
• Thread scheduler doesnt control these.

7
Pitfall Multiple Schedulers

• Every resource with multiple waiting threads has
  a scheduler.
• Locks, disk driver, memory allocator.
• The schedulers may not cooperate or even be
  explicit.

8
Pitfall Server Processes

• User-level servers schedule requests.
• X11, DNS, NFS.
• They usually dont know about kernels scheduling
  policy.
• Network packet scheduling also interferes.

9
Pitfall Hardware Schedulers

• Memory system scheduled among CPUs.
• I/O bus scheduled among devices.
• Interrupt controller chooses next interrupt.
• Hardware doesnt know about O/S policy.
• O/S often doesnt understand hardware.

10
Scheduling is a System Problem

• Thread/process scheduler cant enforce policies
  by itself.
• Needs cooperation from
• All resource schedulers.
• Software structure.
• Conflicting goals may limit effectiveness.

11
Example UNIX

• Goals
• Simple kernel concurrency model.
• Limited pre-emption.
• Quick response to device interrupts.
• Many kinds of execution environments.
• Some transitions are not possible.
• Some transitions cant be controlled.

12
UNIX Environments
User
Kernel
Timer Soft Interrupt
Network Soft Interrupt
Device Interrupt
Device Interrupt
Timer Interrupt
13
UNIX Process User Half

• Interruptable.
• Pre-emptable via timer interrupt.
• We dont trust user processes.
• Enters kernel half via system calls, faults.
• Save user state on stack.
• Raise privilege level.
• Jump to known point in the kernel.
• Each process has a stack and saved registers.

14
UNIX Process Kernel Half

• Executes system calls for its user process.
• May involve many steps separated by sleep().
• Interruptable.
• May postpone interrupts in critical sections.
• Not pre-emptable.
• Simplifies concurrent programming.
• No context switch until voluntary sleep().
• No user process runs if a kernel half is
  runnable.
• Each kernel half has a stack and saved registers.
• Many processes may be sleep()ing in the kernel.

15
UNIX Device Interrupts

• Device hardware asks CPU for an interrupt.
• To signal new input or completion of output.
• Cheaper than polling, lower latency.
• Interrupts take priority over u/k half.
• Save current state on stack.
• Mask other interrupts.
• Run interrupt handler function.
• Return and restore state.
• The real-time clock is a device.

16
UNIX Soft Interrupts

• Device interrupt handlers must be short.
• Expensive processing deferred to soft intr.
• Cant do it in kernel-half process not known.
• Example TCP protocol input processing.
• Example periodic process scheduling.
• Devices can interrupt soft intr.
• Soft intr has priority over user kernel
  processes.
• But only entered on return from device intr.
• Similar to async callback.
• Cant be high-pri thread, since no pre-emption.

17
UNIX Environments
User
Kernel
Soft Interrupt
Device Interrupt
Transfer w/ choice
Transfer, limited choice
Transfer, no choice