1. Advanced Operating Systems (CS 202) Scheduling (1)
Jan, 18, 2019

2. Administrivia Lab has been released
You may work in pairs
Some more details about how to test your implementation may be added
But feel free to come up with your own
Sorry about short lead time for critiques
Will try to release reading one week ahead
We will drop your worse 2 critiques

3. On Microkernel construction (L3/4)

4. L4 microkernel family
Successful OS with different offshoot distributions
Commercially successful
OKLabs OKL4 shipped over 1.5 billion installations by 2012
Mostly qualcomm wireless modems
But also player in automative and airborne entertainment systems
Used in the secure enclave processor on Apple’s A7+ chips
All iOS devices have it! 100s of millions

5. Big picture overview Conventional wisdom at the time was:
Microkernels offer nice abstractions and should be flexible
…but are inherently low performance due to high cost of border crossings and IPC
…because they are inefficient they are inflexible
This paper refutes the performance argument
Main takeaway: its an implementation issue
Identifies reasons for low performance and shows by construction that they are not inherent to microkernels
10-20x improvement in performance over Mach
Several insights on how microkernels should (and shouldn’t) be built
E.g., Microkernels should not be portable

6. Paper argues for the following
Only put in anything that if moved out prohibits functionality
Assumes:
We require security/protection
We require a page-based VM
Subsystems should be isolated from one another
Two subsystems should be able to communicate without involving a third

7. Abstractions provided by L3
Address spaces (to support protection/separation)
Grant, Map, Flush
Handling I/O
Threads and IPC
Threads: represent the address space
End point for IPC (messages)
Interrupts are IPC messages from kernel
Microkernel turns hardware interrupts to thread events
Unique ids (to be able to identify address spaces, threads, IPC end points etc..)

8. Debunking performance issues
What are the performance issues?
Switching overhead
Kernel user switches
Address space switches
Threads switches and IPC
Memory locality loss
TLB
Caches

9. Mode switches System calls (mode switches) should not be expensive
Called context switches in the paper
Show that 90% of system call time on Mach is “overhead”
What? Paper doesn’t really say
Could be parameter checking, parameter passing, inefficiencies in saving state…
L3 does not have this overhead

10. Thread/address space switches
If TLBs are not tagged, they must be flushed
Today? x86 introduced tags but they are not utilized
If caches are physically indexed, no loss of locality
No need to flush caches when address space changes
Customize switch code to HW
Empirically demonstrate that IPC is fast

11. Review: End-to-end Core i7 Address Translation
L2, L3, and
main memory
CPU
32/64
L2, L3, and
main memory
Result
Virtual address (VA) 36 12
VPN
VPO L1
miss L1
hit 32 4
TLBT
TLBI
L1 d-cache
(64 sets, 8 lines/set)
TLB
hit
TLB
miss
...
...
L1 TLB (16 sets, 4 entries/set) 9 9 9 9 40 12 40 6 6
VPN1
VPN2
VPN3
VPN4
PPN
PPO CT CI CO
Physical
address
(PA)
CR3
PTE
PTE
PTE
PTE
Page tables

12. Tricks to reduce the effect
TLB flushes due to AS switch could be very expensive
Since microkernel increases AS switches, this is a problem
Tagged TLB? If you have them
Tricks with segments to provide isolation between small address spaces
Remap them as segments within one address space
Avoid TLB flushes

13. Memory effects
Chen and Bershad showed memory behavior on microkernels worse than monolithic
Paper shows this is all due to more cache misses
Are they capacity or conflict misses?
Conflict: could be structure
Capacity: could be size of code
Chen and Bershad also showed that self-interference more of a problem than user-kernel interference
Ratio of conflict to capacity much lower in Mach
 too much code, most of it in Mach

14. Conclusion Its an implementation issue in Mach
Its mostly due to Mach trying to be portable
Microkernel should not be portable
It’s the hardware compatibility layer
Example: implementation decisions even between 486 and Pentium are different if you want high performance
Think of microkernel as microcode

15. Today: CPU Scheduling

16. The Process The process is the OS abstraction for execution
It is the unit of execution
It is the unit of scheduling
It is the dynamic execution context of a program
A process is sometimes called a job or a task
A process is a program in execution
Programs are static entities with the potential for execution
Process is the animated/active program
Starts from the program, but also includes dynamic state

17. (Dynamic Memory Alloc)
Process Address Space
0xFFFFFFFF
Stack SP
Dynamic
Heap
(Dynamic Memory Alloc)
Address
Space
Static Data
(Data Segment)
Static
Code
(Text Segment) PC 0x

18. Process State Graph Create Process New Ready I/O Done
Unschedule Process
Schedule Process
Waiting
I/O, Page Fault, etc.
Terminated
Running
Process Exit

19. Threads Separate dual roles of a process
Resource allocation unit and execution unit
A thread defines a sequential execution stream within a process (PC, SP, registers)
A process defines the address space, and resources (everything but threads of execution)
A thread is bound to a single process
Processes, however, can have multiple threads
Threads become the unit of scheduling
Processes are now the containers in which threads execute
Processes become static, threads are the dynamic entities
Mach, Chorus, NT, modern Unix

20. Threads in a Process Stack (T1) Thread 1 Stack (T2) Thread 2
Heap
Static Data
PC (T3)
PC (T2)
Code
PC (T1)
CSE 153 – Lecture 4 – Threads

21. Thread Design Space One Thread/Process One Thread/Process
One Address Space (MSDOS)
Many Address Spaces (Early Unix)
Address Space
Thread
Many Threads/Process
Many Threads/Process
One Address Space (Pilot, Java)
Many Address Spaces (Mac OS, Unix, Windows)
CSE 153 – Lecture 4 – Threads

22. Today: CPU Scheduling
Scheduler runs when we context switching among processes/threads on the ready queue
What should it do? Does it matter?
Making the decision on what thread to run is called scheduling
What are the goals of scheduling?
What are common scheduling algorithms?
Lottery scheduling
Scheduling activations
User level vs. Kernel level scheduling of threads

23. Scheduling
Right from the start of multiprogramming, scheduling was identified as a big issue
CCTS and Multics developed much of the classical algorithms
Scheduling is a form of resource allocation
CPU is the resource
Resource allocation needed for other resources too; sometimes similar algorithms apply
Requires mechanisms and policy
Mechanisms: Context switching, Timers, process queues, process state information, …
Scheduling looks at the policies: i.e., when to switch and which process/thread to run next

24. Preemptive vs. Non-preemptive scheduling
In preemptive systems where we can interrupt a running job (involuntary context switch)
We’re interested in such schedulers…
In non-preemptive systems, the scheduler waits for a running job to give up CPU (voluntary context switch)
Was interesting in the days of batch multiprogramming
Some systems continue to use cooperative scheduling
Example algorithms: RR, Shortest Job First (how to determine shortest), …

25. Scheduling Goals Mix? What are some reasonable goals for a scheduler?
Scheduling algorithms can have many different goals:
CPU utilization
Job throughput (# jobs/unit time)
Response time (Avg(Tready): avg time spent on ready queue)
Fairness (or weighted fairness)
Other?
Non-interactive applications:
Strive for job throughput, turnaround time (supercomputers)
Interactive systems
Strive to minimize response time for interactive jobs
Mix?

26. Goals II: Avoid Resource allocation pathologies
Starvation no progress due to no access to resources
E.g., a high priority process always prevents a low priority process from running on the CPU
One thread always beats another when acquiring a lock
Priority inversion
A low priority process running before a high priority one
Could be a real problem, especially in real time systems
Mars pathfinder:
Other
Deadlock, livelock, convoying …

27. Non-preemptive approaches
Introduced just to have a baseline
FIFO: schedule the processes in order of arrival
Comments?
Shortest Job first

28. Preemptive scheduling: Round Robin
Each task gets resource for a fixed period of time (time quantum)
If task doesn’t complete, it goes back in line
Need to pick a time quantum
What if time quantum is too long?
Infinite?
What if time quantum is too short?
One instruction?
Can we combine best of both worlds? Optimal like SJF, but without starvation?

29. Mixed Workload
I/O task has to wait its turn for the CPU, and the result is that it gets a tiny fraction of the performance it could get.
By contrast the compute bound
We could shorten the RR quantum, and that would help, but it would increase overhead.
what would this do under SJF? Every time the task returns to the CPU, it would get scheduled immediately!

30. Priority Scheduling Priority Scheduling Problem? Solution
Choose next job based on priority
Airline check-in for first class passengers
Can implement SJF, priority = 1/(expected CPU burst)
Also can be either preemptive or non-preemptive
Problem?
Starvation – low priority jobs can wait indefinitely
Solution
“Age” processes
Increase priority as a function of waiting time
Decrease priority as a function of CPU consumption

31. More on Priority Scheduling
For real-time (predictable) systems, priority is often used to isolate a process from those with lower priority. Priority inversion is a risk unless all resources are jointly scheduled.
x->Acquire() PH
priority
time
x->Acquire()
x->Release() PL
x->Acquire()
How can this be avoided? PH
priority
time PM
x->Acquire() PL

32. Combining Algorithms Scheduling algorithms can be combined
Have multiple queues
Use a different algorithm for each queue
Move processes among queues
Example: Multiple-level feedback queues (MLFQ)
Multiple queues representing different job types
Interactive, CPU-bound, batch, system, etc.
Queues have priorities, jobs on same queue scheduled RR
Jobs can move among queues based upon execution history
Feedback: Switch from interactive to CPU-bound behavior

33. Multi-level Feedback Queue (MFQ)
Goals:
Responsiveness
Low overhead
Starvation freedom
Some tasks are high/low priority
Fairness (among equal priority tasks)
Not perfect at any of them!
Used in Unix (and Windows and MacOS)

34. MFQ

35. Unix Scheduler The canonical Unix scheduler uses a MLFQ
3-4 classes spanning ~170 priority levels
Timesharing: first 60 priorities
System: next 40 priorities
Real-time: next 60 priorities
Interrupt: next 10 (Solaris)
Priority scheduling across queues, RR within a queue
The process with the highest priority always runs
Processes with the same priority are scheduled RR
Processes dynamically change priority
Increases over time if process blocks before end of quantum
Decreases over time if process uses entire quantum

36. Linux scheduler Went through several iterations Currently CFS
Fair scheduler, like stride scheduling
Supersedes O(1) scheduler: emphasis on constant time scheduling regardless of overhead
CFS is O(log(N)) because of red-black tree
Is it really fair?
What to do with multi-core scheduling?