1 / 30

Processes and Schedulers

Processes and Schedulers. 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

paloma
Télécharger la présentation

Processes and Schedulers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related