Processes and Schedulers

1. Processes and Schedulers

2. What is a Process • Process: An execution stream and its associated state • Execution Stream • Set of instructions • “Thread of control” • Process State • Hardware state • Privilege level, segments, page tables • OS State • Priority, I/O Buffers, Heap, memory map • Resource state • I/O requests • An abstraction to make it easier to program both OS and applications • Encapsulate state into manageable unit

3. Programs and Processes • A process is not a program • Program: Static code and static data Program Process int foo() { return 0; } int main() { foo(); return 0; } int foo() { return 0; } int main() { foo(); return 0; } Heap Stack Registers • OS can host multiple processes of same program • E.g. many users can run ‘ls’ at the same time • Once program can invoke multiple processes • E.g. make runs many processes to compile code • No one-to-one mapping between programs and processes

4. Threads and Processes • A process is different than a thread • Conceptually (On Linux it is more complicated) • Thread: Separate execution streams in same address space • “Lightweight process” Process int foo() { return 0; } int main() { foo(); return 0; } Heap Threads Stack int foo() { return 0; } int main() { foo(); return 0; } Heap Registers Stack Stack Registers Registers • Can have multiple threads within a process

5. System Classification • Uniprogramming: Only one process at a time • Examples: Original systems and older PC Oses • DOS • Advantages: Easier for OS designer • Disadvantages: Terrible utilization, poor usability • Multiprogramming: Multiple processes at a time • Examples: Every modern OS you use • Note: Multiprogramming is different from multiprocessing • Multiprocessing: Systems with multiple processors • Advantages: Better utilization and usability • Disadvantages: Complex OS design

6. Multiprogramming • OS requirements for multiprogramming • Policy to determine process to run • Mechanism to switch between processes • Methods to protect processes from one another • Memory management system • Separation of policy and mechanism • Recurring theme in OS design • Policy: Decision maker based on some metric • Scheduler • Mechanism: Low level code that implements the decision • Dispatcher/Context Switch

7. Multiprogramming and Memory • Many OSesdidn’t do a very good job of combining these • Early PC OSes didn’t protect memory • MacOS and Windows • Each process could access all of memory • Same address space • Basically a giant multithreaded environment • All modern OSes not include memory map in PCB • Processes cannot access each other memory

8. Dispatch Mechanism • OS maintains list of all processes • Each process has a mode • Running: Executing on the CPU • Ready: Waiting to execute on CPU • Blocked: Waiting for I/O or synchronization with another thread • Dispatch Loop while (1) { run process for a while; stop process and save its state; load state of another process; } How does dispatcher gain control? What execution state must be saved/restored?

9. How does dispatcher gain control? • Must change from user to system mode • Problem: Only one CPU, and CPU can only do one thing at a time • A user process running means the dispatcher isn’t • Two ways OS gains control • Traps: Events caused by process execution • System calls, page faults, Exceptions (segfault, etc) • Hardware interrupts: Events external to process • Typing at keyboard, network packet arrivals • Control switch to OS via Interrupt Service Routine (ISR) • How does OS guarantee it will regain control?

10. Approaches to dispatcher • Option 1: Cooperative multitasking • Trust process to invoke dispatcher • Linux: Default for kernel code • schedule() • Disadvantage: A mistake in one part of the code can lock up entire system • Option 2: True multitasking • Configure hardware to periodically invoke dispatcher • Hardware generated timer interrupt • Timer ISR invokes dispatcher • Linux: Enabled for user processes • 100-1000HZ • Processes run for some multiple of timer “ticks” (interrupts) • Process time slice

11. What state must be saved? • OS must track state of processes • On every trap/interrupt save process state in “process control block” (PCB) • Why on every trap/interrupt? • Data structure problem: How to manages all PCBs • Information stored in PCB • Execution state • General registers, control registers, CPU flags, RSP, RIP, page tables • OS state • Memory map, heap space • I/O status • Open files and sockets • Scheduling information • Execution mode, priority • Accounting information • Owner, PID • Plus lots more

12. Context Switch implementation • Machine dependent code (Assembly!) • Different for MIPS, ARM, x86, etc. • Save process state to PCB • Tricky: OS must save state without changing state • Requires special hardware support • Save process state on each trap/interrupt • Very nasty • x86 has TSS (PCB) that most OSes avoid

13. Process Creation • Two ways to create a process • Build one from scratch • Clone an existing one • Option 1: From scratch (Windows – CreateProcess(…)) • Load specified code and data into memory • Create empty call stack • Create and initialize PCB (make it look like a context switch) • Add process to ready list • Option 2: Cloning (UNIX – fork()) • Stop current process and save its state • Copy code, data, stack and PCB • Add new Process PCB to ready list • Do we really need to copy everything?

14. Creating a process (Windows and UNIX) Windows BOOL WINAPI CreateProcess( _In_opt_    LPCTSTR lpApplicationName, _Inout_opt_ LPTSTR lpCommandLine, _In_opt_  LPSECURITY_ATTRIBUTES lpProcessAttributes, _In_opt_    LPSECURITY_ATTRIBUTES lpThreadAttributes, _In_        BOOL bInheritHandles, _In_        DWORD dwCreationFlags, _In_opt_    LPVOID lpEnvironment, _In_opt_    LPCTSTR lpCurrentDirectory, _In_        LPSTARTUPINFO lpStartupInfo, _Out_       LPPROCESS_INFORMATION lpProcessInformation ); UNIX int fork();

15. Creating processes in UNIX • Combination of fork() and exec(…) • fork(): Clone current process • exec(…): copy new program on top of current process int main() { intpid; char * cmd = “/bin/sh”; pid = fork(); if (pid == 0) { // child process exec(cmd); // exec does not return, WE NEVER GET HERE } else { // parent process – wait for child to finish wait(pid); } } • Advantage: Flexible, clean, simple

16. Process Abstraction • Processes are a low level component • Provide an abstraction to build on • Fundamental OS design • Provide abstract units (resources) that high level policies can act on • Resources • Resources are high level units managed by OS • CPU time, memory, disk space, I/O bandwidth • How does the OS manage resources?

17. Resources • Preemptible • Resource can be taken away and used by somebody else • Example: CPU • Non-preemptible • One a resource is assigned it can only be returned voluntarily • Example: Disk space • OS must balance set of resources and requests for those resources • OS management depends on type of resource

18. Decisions about Resources • Allocation: Which process gets which resource • Which resources should each process get? • Space sharing: Control concurrent access to resource • Implication: Resources are not easily preemptible • Example: disk space • Scheduling: How long process keeps resource • In which order should requests be serviced • Time sharing: More resources requested than exist • Implication: Resource is preemtible • Example: CPU time

19. Role of Dispatcher vs. Scheduler • Dispatcher • Low-level mechanism • Responsibility: Context-switch • Change mode of old process to either WAITING or BLOCKED • Save execution state of old process in PCB • Load state of new process from PCB • Change mode of new processes to RUNNING • Switch to user mode privilege • Jump to process instruction • Scheduler • Higher level policy • Responsibility: Decide which process to dispatch to • CPU could be allocated • Parallel and Distributed Systems

20. Scheduling Performance Metrics • Minimize response time • Increase interactivity (responsiveness of user interfaces) • Maximize resource utilization • Keep CPU and disks busy • Minimize overhead • Reduce context switches (number and cost) • Distributed resources fairly • Give each user/process same percentage of CPU

21. Scheduling Algorithms • Process (job) model • Process alternates between CPU and I/O bursts • CPU bound job: long CPU bursts • I/O bound job: short CPU bursts • Don’t know before execution • Need to handle full range of possible workloads • Scheduling Algorithms • First-Come-First-Served (FCFS) • Shortest Job First (SJF) or Shortest-Time-Completion-First (STCF) • Round-Robin (RR) • Priority Scheduling • Other scheduling algorithms that are actually used

22. First Come First Served (FCFS) • Simplest Scheduling algorithm • First job that requests CPU is allocated CPU • Nonpreemptive • Advantage: Simple Implementation with FIFO queue • Disadvantage: Response time depends on arrival order • Unfair to later jobs (especially if the system has long jobs) Job A Job B Job C CPU Time • Uniprogramming: Run job to completion • Multiprogramming: Put job at back of queue when performing I/O

23. Convoy Effect • Short running jobs stuck waiting for long jobs • Example: 1 CPU bound job, 3 I/O bound jobs • Problems • Reduces utilization of I/O devices • Hurts response time of short jobs B A C C B A C C CPU B A C C A C C B Idle Idle Disk Time

24. Shortest Job First • Minimizes average response time Job B Job C Job A CPU Time • FCFS if simultaneous arrival • Provably optimal (given no preemption) to reduce response time • Short job improved more than long job is hurt • Not practical: Cannot know burst lengths (I/O + CPU) • Can only use past behavior to predictfuture behavior

25. Shortest Time to Completion First (STCF) • SJF with preemption • New process arrives w/ short CPU burst • Shorter than remaining time of current job Job Submission: A at time 0, B/C/D at time t A B D A C CPU 0 t Time • SJF without preemption A B D C CPU Time

26. Shortest Remaining Processing Time(SRPT) • STCF for batch workloads • Used in distributed systems • Provides maximum throughput (transactions/sec) • Minor risk of starvation • Very popular in web servers and similar systems

27. Round Robin (RR) • Practical approach to support time-sharing • Run job for a time-slice and then go to back of queue • Preempted if still running at end of time-slice • Advantages • Fair allocation of CPU across jobs • Low average response time when job lengths vary widely • Avoids worst case scenarios and starvation A B C A B A B C A CPU Time

28. Disadvantages of Round Robin • Poor average response time when job sizes are identical • E.g. 10 jobs each require 10 time slices • All complete after 100 time slices • Even FCFS is better • How large should the time slice be? • Depends on the workload! • Tradeoff between throughput and responsiveness • Batch vs. interactive workloads

29. Priority based scheduling • Priorities assigned to each process • Run highest priority job in system (that is ready) • Round robin among equal priority levels • Aside: How to parse priority numbers • Is low high or is high high? (Depends on system) • Static vs. Dynamic priorities • Some jobs have static priority assignments (kernel threads) • Others need to be dynamic (user applications) • Should priorities change as a result of scheduling decisions?

30. Real world scheduling • Current schedulers exhibit combinations of above approaches • Include priorities, round robin queues, queue reordering, and much more • There is no single good algorithm • Nor is there a way to even measure “goodness” • Most schedulers designed based on heuristics and best guesses of potential workloads • Linux has a lot of complexity to detect batch vs. interactive processes (can change during execution) • Many times a scheduler will work great 99% of the timebut completely fall over for 1% of workloads