170 likes | 405 Views
Traditional OS Processes and Scheduling. Lecture 15hb. Summary of Previous Lecture. Virtual memory Virtual addresses Page tables Page faults; thrashing. Administrivia. Quiz #3 in the second half of today’s lecture Will be open book/open notes Mid-Term Exam Will be open book/open notes
E N D
Traditional OS Processes and Scheduling Lecture 15hb
Summary of Previous Lecture • Virtual memory • Virtual addresses • Page tables • Page faults; thrashing
Administrivia • Quiz #3 in the second half of today’s lecture • Will be open book/open notes • Mid-Term Exam Will be open book/open notes • Mid-term grades will be based on Quizzes #1-3 and Labs 1-2
Outline of This Lecture • Why also understand traditional OS processes and scheduling? • Unix processes • Traditional Unix Scheduling
Why Understand Traditional OS Notions? • To understand what is possible, • To understand what is done on traditional OSs, • Most importantly, to understand how and why embedded (real-time) operating systems are common in some aspects and different in other aspects
Dispatching • The dispatcher (shortterm scheduler) is the entity responsible for adding a process/thread to the run queue. • It is invoked by the scheduler upon an event • Examples include: • End of a quantum • End of a period • End of a process • End of a thread • This thread of execution is explicitly invoked when something happens • The thread is, however, loaded up in memory. • Where? • What is the address space of this thread?
Address Spaces • Each heavyweight process has its own address space • Each thread shares its address space and global data structures with other threads in the same process • There are provisions to share memory among heavyweight processes: shared memory • In Unix, you have to explicitly declare the shmem, get an id for the area, attach yourself to it. • Another way of sharing some info is between parent and child processes • They share the list of open files and the code of the process (executable image)
Forking and Processes • When a Unix process calls a fork() at some point in the code, a new (child) process becomes ready at the same point of the parent process • How does one define who is the parent (child) process? • PID = fork() returns a process identifier (PID) • In the child process, the value of the PID is zero • In the parent process, PID contains the child's PID • This PID is useful for the parent process to keep track of all its children • e.g., who is alive, who terminated
What happens on a fork() call? if (PID == 0) { /* this is the child process; * add your code here for a small fee */ } else { children[current_child] = PID; current_child++; /* this is the rest of the parent * process; continue your code here * E.g.: wait for your child process to * come back. */ }
UNIX Processes • The bootstrap program will start the init process • init is the parent of all processes • It will fork off terminal processes (tty) by reading the /etc/ttys file • Each terminal has a process associated with it • e.g., it is this process that prints the “prompt”, does validation of userid/password and then waits for input • Many of the user (shell) commands will fork off a new process to work on the user commands.
Unix • On the other hand, some processes are initialized by the kernel itself (after all the main functions were put in place correctly). • In Unix, processes that run in the background, such as printing or the ftp manager, are called daemons • These daemons complement the kernel functionality • Everything in Unix is a process and the kernel is stiff (single locus of execution) but efficient
Unix Scheduling • The problem with multiple queues is starvation • This can be solved by aging, which means that the longer a process executes, the higher its priority • Unix scheduling is round-robin with multilevel feedback • It computes the priority of the processes according to the user directives, resource usage and aging • User directives: nice command (positive integer) • Resource usage is computed by the kernel • Aging is computed by increasing the priority of the process every quantum regardless of anything else
Unix Scheduling (cont) • The algorithm for setting the priority, at each quantum: • CPU_usage = CPU_usage/2 • priority = CPU_usage/2 + base_priority + nice_level • base_priority is typically set to 70 • nice_level is typically 0, unless nice command is used • CPU_usage starts out as 0, clearly • Initial priority starts out the same as base_priority • Does this algorithm actually give higher priority to aging processes? • Does it take into consideration resource usage?
Example of UNIX scheduler • Quantum 1sec, base priority 60, nice 0, init priority 0 • Clock interrupts the system 60 times/sec (or 60 times/quantum) • At each interrupt, CPU usage is incremented • Thus, in one quantum, CPU usage increases by 60 • At every quantum, kernel performs calculations • CPU = decay(CPU) = CPU/2 • Process priority = (CPU/2) + 60 time procA procB procC pr CPU pr CPU pr CPU 0 60 0 60 0 60 0 1 75 60,30 60 0 60 0 2 67 15 75 60,30 60 0 3 63 7 67 15 75 60,30 4 76 67,33 63 7 67 15 5 68 16 76 67,33 63 7
More on Unix Scheduling • Priorities in Unix are divided into Kernel and User • Some processes executing with Kernel priority are nonpreemptable • e.g., diskrelated system calls • Processes executing with User priority are preemptable • user processes, or system functions executing for the user • Unix grants higher priorities to processes waiting for lowerlevel algorithms (e.g., disk read/write). • why? • UNIX disregards the job characteristics • e.g., IObound or CPUbound processes when scheduling
Summary of Lecture • Dispatching • Unix as an example of a traditional general-purpose OS • Unix processes and threads • Unix Scheduling • Looking at “top” • GOOD LUCK FOR QUIZ #3!!