6 Operating System Principles—Unix School
59
161 6 Operating System Principles—Unix School • We have seen that controlling a digital computer can be a quite challenging task, e.g., controlling the CPU ≡ construct machine- or assembly-level programs • A computer system, however, comprises more vital components and resources which need to be managed as well:
Transcript of 6 Operating System Principles—Unix School
161
6 Operating System Principles—Unix School
• We have seen that controlling a digital computer can be a quite
challenging task, e.g.,
controlling the CPU ≡ construct machine- or assembly-level programs
• A computer system, however, comprises more vital components and
resources which need to be managed as well:
162
Operating System Principles
• It is infeasible to interact with this diversity of components on an
“assemby-style” level: the incurred complexity becomes intractable
Example (programming the floppy-disk controller chip PD765):
PD765 Feature Programming Interface# of commands 16specify command write up to 9 bytes to controller registers
(e.g., MIPS: sb $t0, controller)command types read/write data, move r/w head, format track,
initialize, status request, reset, calibrate, . . .READ command 13 parameters packed into 9 bytes (track/block,
# sectors per track, sector gap length, . . . )command completion 23 controller status flags packed into 7 bytesmotor control explicit start/stop commands, manual r/w delay after
motor start needed, manual idle spin down needed
• We clearly want a floppy controller interface on a higher level of
abstraction (e.g., open file, read n bytes, format disk)
163
Operating System Principles
• An operating system (OS) is a collection of interacting programs
which provide such abstractions of
1© external devices (floppy/hard disks, printers, keyboards, serial and
parallel I/O ports, network adapters, . . . ), and
2© internal resources (main memory, CPU(s))
• We will now review some basic principles of computer system operation as
these directly influence the way OSs are designed
164
Computer Systems Architecture
• Controllers are independent (highly specialized) processors on their own
165
Computer System Operation
• I/O devices and the CPU can execute concurrently
• Each device controller is in charge of a particular device type
(not shown on previous slide: network adapter, graphics controller)
• Each device controller has a local memory buffer, the controller can
move data from the local buffer to the device without system bus activity
• To perform I/O, CPU copies data (via system bus) from/to local buffers
of controller
• Device controller informs CPU that it has finished its I/O operation by
causing an interrupt
166
Interrupt Handling
• Whole OS is interrupt driven:
1© Device controller initiates interrupt #n
2© CPU saves register (including current address of IP)
3© CPU performs lookup in interrupt vector for interrupt #n, retrieves
address of interrupt service routine; Linux 2.4 interrupt vector:Interrupt #n Service routine
0 timer (countdown)1 keyboard3 serial port8 real time clock11 ethernet, usb, pcmcia, graphics12 mouse (PS/2)14 ide (CD-ROM, hard disk)
4© CPU disables further incoming interrupts, executes service routine,
then re-enables interrupts
5© CPU restores saved state, returns to interrupted program
167
Interrupt Timing
• CPU executes user program; program initiates I/O request (e.g., write
512 bytes to disk):
• Note: the program is able to continue to execute while the I/O device is
completing the request (I/O request −→ transfer done)
168
Synchronous vs. Asynchronous I/O
• What happens during the I/O request −→ transfer done period?
1© Synchronous I/O:
– Control returns to user program only after I/O completed:� Special wait instruction halts CPU until next interrupt,
or� CPU performs busy wait loop
2© Asynchronous I/O:
– Control returns to user program immediately after I/O starts
– Program may wait voluntarily for OS to complete I/O
– OS keeps device status table to maintain list of all outstanding
I/O requests
169
Synchronous vs. Asynchronous I/O
• Note: kernel ≡ core routines of OS software
170
Device Status Table
• With asynchronous I/O, requests for a single device may queue up
• OS maintains device status table (“ToDo list”) for each device to keep
track of yet unfulfilled requests:
171
Magnetic Disk Storage
• Main memory (RAM, random access memory) is the only large storage
media the CPU can access directly, volatile
• Secondary storage: extension of main memory that provides large,
non-volatile storage capacity
• Magnetic disks:
– Rigid metal or glass platters, surface covered with magnetic recording
material
– Platters rotate at high speed (≈ 5000–10000 rpm)
– Disk surface is logically divided into concentric tracks, which are
subdivided into sectors
– Arm moves read/write head from track to track
– I/O transfers are performed sector-by-sector (or multiples thereof,
typically 4 or 8 kB)
172
Magnetic Disk Mechanism
• Reading/writing a specific sector incurs several delays:
1© disk heads have to be moved to desired track (seek time) +
2© controller waits for desired sector to rotate under head (rotational
delay) +
3© sector data has to be read/written (transfer time)
173
Magnetic Disks—Access Time
access time = 1© seek time+ 2© rotational delay+ 3© transfer time
• Example (access time for hard disk model IBM Deskstar 14GPX):
– 3.5 inch platter diameter, 14.4 GB capacity (formatted)
– 5 platters of 3.35 GB of user data each, platters rotate at 7200 rpm
– average seek time 9.1 ms (min: 2.2 ms [track-to-track], max: 15.5 ms)
– average rotational delay 4.17 ms
– data transfer rate 13 MB/s
access time 8 KB = 9.1 ms + 4.17 ms +1 s
13 MB/8 KB≈ 13.87 ms
• NB. Accessing a main memory location typically takes 50 ns (50 · 10−9 s)!
174
The Storage Hierarchy
• The diverse forms of storage media form a hierarchy
(top to bottom: speed ↘ size ↗ cost/bytes ↘)
– Note: electronic disk ≡ e.g., USB memory sticks, flash memory
175
Caching in the Storage Hierachy
Example (perform find file search twice on hard disk under Linux control,
observe and compare execution times):
$ find / -size +100000k 2> /dev/null
• To make up for the drastically increasing access times in the lower
hierarchy levels, the OS caches data that has been read from a lower level
in main memory
– Cache: main memory buffer of limited size that holds recently read
data or data that is anticipated to be requested soon by a program
– When data is requested from disk, the cache is consulted first—only if
the requested data cannot be found in the cache (cache miss), I/O is
initiated
176
Protection
• A modern OS protects itself from buggy or malicious user programs
• OSs that run multiple programs concurrently, protect programs from
interfering (each program is provided with the illusion it owns the system)
• CPU and system hardware supports two modes of operation:
Mode Commentuser mode user program execution,
direct hardware access causes fault
monitor mode14 OS kernel executionaccess to I/O controllers
montitor user
interrupt / fault
set user mode
14Also: privileged mode, protected mode, supervisor mode, kernel mode
177
Memory Protection
• A program p may not read/write memory regions that have not explicitly
been assigned to p (p may not alter OS or other program memory)
• Memory accesses outside the assgined range result in a memory
protection fault (or segmentation fault) ⇒ OS gets control and
aborts the guilty program
Example (C program writing outside assigned memory range):
int main ()
{
/* allocate a 1 KB memory range for this program,
* lowest address in range is mem, highest address is mem + 1023 */
char *mem = (char *) malloc (1024);
/* write access outside the assigned memory range�
*/
*(mem + 7000) = ’X’;
printf ("Success writing outside memory range!");
}
178
Timer Interrupts
• Hardware supports timer circuits (countdown circuits):
1© CPU loads timer with predefined start value
(privileged instruction, available in monitor mode only)
2© Hardware decrements timer in synchronization with system clock
3© When timer reaches 0, timer interrupt occurs
• Used by the OS
– to implement current time of day,
– to implement high-resolution stopwatch services to programs,
– to ensure that control returns to OS after a well-defined time
(user programs cannot monopolize the CPU)
Example (concurrently run two programs writing to Linux console):
$ ./write O & ./write X &
179
write X.c, write O.c
#include <sys/select.h>int main (){
/* loop forever */while (1) {
/* request sleeping for 500 ms (1/2 second) */struct timeval tm = { .tv_sec = 0, .tv_usec = 5000 };select (1, 0, 0, 0, &tm);
/* write "X" to terminal */write (1, "X", 1);
}}
#include <sys/select.h>int main (){
/* loop forever */while (1) {
/* request sleeping for 500 ms (1/2 second) */struct timeval tm = { .tv_sec = 0, .tv_usec = 500 };select (1, 0, 0, 0, &tm);
/* write "O" to terminal */write (1, "O", 1);
}}
180
System Calls
• System calls are well-defined entry points into the OS, user programs
invoke a system call to request a specific service (e.g., open a file, write
characters to console) from the OS
– During the system call, the system switches from user to monitor mode
– On Intel x86 CPUs, switching to monitor mode is performed via a
software interrupt (or trap) via the x86 CPU instruction
int n # invoke interrupt n
Example (invoke Linux system call trap, interrupt 0x80, request open a
file, service #5)
movl $0x5, %eax # load sys.call code for open into register eax
int $0x80 # trap (switches to monitor mode)
– Note: compare this to SPIM’s syscall
181
Linux: invoking system call open
• C program to open file named foo.txt for writing:
int main ()
{
/* open file "foo.txt" for writing */
open ("foo.txt", 1);
}
• Intel x86 assembly code, produced by C compiler gcc for the above
program (excerpt):.file "open.c"
.LC0:.string "foo.txt".text
.globl mainmain:
.
.pushl $1pushl $.LC0call open # MIPS: jal open..
182
Linux: invoking system call open
• Inside the Linux C library which implements the open function:
__libc_open:
.
.
.
mov 0xc(%esp,1),%ecx # push arguments for open ...
mov 0x8(%esp,1),%ebx # ... onto stack
mov $0x5,%eax # Linux system call code ‘open’
int $0x80 # switch to monitor mode
.
.
.
ret # return to user program
183
Linux: invoking system call open
• Inside the Linux kernel (file entry.S), this code is reached whenever trap
0x80 has been invoked:
.textsystem_call:
.
.
.cmpl $(NR_syscalls),%eax # check system call code sanityjae badsys # eax >= NR_syscalls? => errorcall *sys_call_table(,%eax,4) # invoke system call routine. # at address sys_call_table + eax * 4..
.datasys_call_table:
.long sys_ni_syscall # code 0
.long sys_exit
.long sys_fork
.long sys_read
.long sys_write
.long sys_open # code 5
.long sys_close
.
.
.
184
Linux: invoking system call open
• Inside the Linux kernel (implementation of the open system call in file
fs/open.c):
long sys_open(const char * filename, int flags, int mode)
{
char * tmp;
int fd, error;
#if BITS_PER_LONG != 32
flags |= O_LARGEFILE;
#endif
tmp = getname(filename);
fd = PTR_ERR(tmp);
if (!IS_ERR(tmp)) {
fd = get_unused_fd();
.
.
.
– Function sys_open is running in monitor mode and may initiate file
creation on hard disk (via the Linux file system layer)
185
Processes
6.1 Processes
• Early OSs operated in batch processing mode:
– programmers would describe a job (usually encoded using punch cards),
– a pile of cards (the batch) would then be fed to the OS,
– the OS executes one job at a time, in batch order, further user
interaction is not required/not possible
• Contemporary OSs (approx. 1965, starting with Multics) support
multi-user, time-sharing operation:
– multiple interactive users are allowed to run multiple jobs concurrently
– CPU time is shared (more or less fairly) among users
186
Processes vs. programs
• The unit of execution now is the program:
1© users start programs manually (via the shell or GUI), these programs
may then start other programs on behalf of the user, or
2© the OS itself starts programs, normally during OS startup (boot) or in
response to a specific event (e.g., plug-in device, timer expired, . . . )
– In the Unix world, these programs are referred to as daemons (disk
and execution monitors)
Example (some Linux daemons):Daemon Purposecron execute chronological activities (“house keeping”)
e.g., every day, every first monday/month, every 5 secssshd accept/manage secure remote login requestsntpd synchronize system clock with external clockgetty print login: prompt, listen on terminal line and allow user login
187
Processes vs. programs
• Note: there is a difference between
1© a program (the machine code file residing on disk), and
2© and the running program (CPU executes the machine instructions)
• A program executed by the OS is referred to as a process
• One or several users may run the same program, but each invocation
creates a new process with a unqiue process identity (PID)
Example (user invokes program /usr/bin/xclock and creates multiple
xclock processes):
$ xclock & xclock & xclock &
$ ps -fp $(pgrep -d, -x xclock)
UID PID PPID C STIME TTY TIME CMD
grust 19563 19503 0 15:33 pts/17 00:00:00 xclock
grust 19564 19503 0 15:33 pts/17 00:00:00 xclock
grust 19565 19503 0 15:33 pts/17 00:00:00 xclock
188
Process life-cycle
• Starting a program creates a new process; at any given time, a process is
in one of the following process states:
– new: the process has just been created
– ready: process could continue to run (any outstanding I/O complete)
– running: the CPU executes instructions of the process’ program
– waiting: process waits for I/O operation to finish/timer to expire
– terminated: execution finished, process may be destroyed
• On single-CPU system, one process is in state running at any instant�
189
Process control blocks• For each process, the OS performs bookkeeping for the process in its
associated process control block (PCB)
– The PCB contains the necessary information which allow the OS� to interrupt the process and later continue to run it,� to remember which I/O requests are outstanding for this process,
which and how many files are used by the process,� to remember which user with which privileges executes the process,
which resources (accumulated CPU time, memory, etc.) are in use:
190
Process switching
191
Process scheduling
• In a (heavily) loaded OS, several processes will be in state ready or state
waiting (for I/O)
– How does the OS decide which process to wake up (state ready →running) or which I/O request to perform next?
• All PCBs of processes in state ready are put into the OS ready queue15
(waiting line), the PCBs form a linked list
• The OS scheduler picks a PCB out of this list and switches the process
from ready to running
– The scheduling algorithm (who’s next?) depends on process priority,
interactivity/responsiveness, real-time requirements, fairness
15Analogously, the OS maintains I/O device queue.
192
Ready queue and I/O device queues
193
Process scheduling
• On Unix, the average length of the ready queue is known as the system’s
load average
$ uptime
5:20pm up 8:18, 7 users, load average: 1.14, 0.46, 0.27
194
Process scheduling
• Scheduling processes in an interactive time-sharing system is a quite
complex task
– The OS needs to make sure that computationally intensive
background processes (number crunchers) receive appropriate time
slices on the CPU, on the other hand
– the OS needs to schedule interactive processes such that
responsiveness does not suffer (short burts of CPU time needed)
Example (simulate badly scheduled interactive X11 client):
$ xfig & # start interactive X11 drawing program
$ seq 1 10000000 # simulation of ‘‘number cruncher’’
$ nice -19 xfig & # restart with minimum scheduling priority
$ seq 1 10000000 # simulation of ‘‘number cruncher’’
195
Unix processes
• Unix-style OSs identify each process by its unique PID (process identifier),
a 32-bit integer value
– The Unix utility ps creates a list of currently active processes:
$ ps -eFl
F S UID PID PPID C PRI NI ADDR SZ WCHAN RSS PSR STIME TTY TIME CMD
0 S root 1 0 0 75 0 - 125 schedu 248 0 09:34 ? 00:00:03 init [5]
0 S root 5 1 0 85 0 - 0 kswapd 0 0 09:34 ? 00:00:00 [kswapd]
0 S root 6 1 0 85 0 - 0 bdflus 0 0 09:34 ? 00:00:00 [bdflush]
0 S root 393 1 0 75 0 - 364 schedu 600 0 09:34 ? 00:00:00 /sbin/syslogd
0 S root 689 1 0 75 0 - 828 schedu 1892 0 09:35 ? 00:00:00 /usr/bin/fetchmail -f /etc/fetchm
0 S ntp 854 1 0 75 0 - 504 schedu 2008 0 09:35 ? 00:00:00 [ntpd]
0 S root 865 1 0 81 0 - 1056 schedu 1504 0 09:35 ? 00:00:00 /usr/sbin/sshd -o PidFile /var/ru
0 S root 1058 1 0 75 0 - 960 schedu 1252 0 09:35 ? 00:00:00 [master]
0 S postfix 1077 1058 0 75 0 - 953 schedu 1200 0 09:35 ? 00:00:00 [pickup]
0 S root 1094 1 0 75 0 - 380 schedu 656 0 09:35 ? 00:00:00 /usr/sbin/cron
0 S root 1167 1 0 79 0 - 341 schedu 480 0 09:35 tty1 00:00:00 /sbin/mingetty --noclear tty1
0 S root 1168 1 0 79 0 - 341 schedu 480 0 09:35 tty2 00:00:00 /sbin/mingetty tty2
0 S root 1176 1174 1 77 0 - 71961 schedu 22080 0 09:35 ? 00:00:48 /usr/X11R6/bin/X :0 vt07 -auth /v
0 S grust 1232 1177 0 75 0 - 1113 wait4 1204 0 09:36 ? 00:00:00 /bin/bash /home/grust/.jws
0 S grust 1269 1232 0 75 0 - 782 schedu 1732 0 09:36 ? 00:00:00 jws
0 S grust 1344 1269 0 80 0 - 357 schedu 560 0 09:36 ? 00:00:00 jterm
0 S grust 1345 1344 0 83 0 - 1161 schedu 1596 0 09:36 pts/6 00:00:00 bash
0 S grust 1355 1269 0 81 0 - 357 schedu 560 0 09:36 ? 00:00:00 jterm
0 S grust 1366 1301 0 75 0 - 8376 schedu 27864 0 09:36 pts/2 00:00:02 emacs -nw -f vm
0 S grust 1370 1263 0 75 0 - 2151 schedu 4460 0 09:36 ? 00:00:00 xterm -sb
0 Z grust 1648 1379 0 80 0 - 0 exit 0 0 09:49 ? 00:00:00 [netstat] <defunct>
0 S grust 1707 1677 0 75 0 - 3454 schedu 9128 0 09:54 pts/9 00:00:02 emacs rs-06.tex
0 R grust 5182 4361 0 81 0 - 935 - 1736 0 10:18 pts/11 00:00:00 ps -eFl
196
Unix process hierachy
• When Unix boots, the first process started is the scheduler, whose PID is
set to 0 (not shown in ps listings)
• The scheduler then starts the init process (PID 1)—init never
terminates and is responsible to start vital system processes (or restart
these processes should they die unexpectedly)
– Which processes are started exactly is determined by the system’s run
level. In each run level, init starts a different set of processes to
configure the system for particular uses:
run level configuration0 system halt1 single user mode (maintenance, root user)2 multi user mode, no networking3 full multi user mode, plus networking4 full multi user mode, plus networking, plus X11 (graphical UI)
197
Unix process creation—fork
• Starting a program in Unix requires the creation of a new process—in
Unix, processes are created via the fork system call
1© The currently running process with PID P1 executes a fork system call
2© Unix creates an identical copy of P1 and assigns a new PID P2 for
the new process
3© The process with PID P1 is called the parent, process P2 is called the
child of the fork
P1 P2fork
parent child
198
Unix process creation—fork
• Unix creates the copy of the process such that
– both processes P1 and P2 may share the same program code
(text), i.e., both processes run the same program, but
– both processes have their own private memory area to store data
(program variables, etc.):
P2forkP1
parent child
data data
text
data data
shared text
• After the fork, both parent and child are exactly in the same state
199
Unix process creation—fork
• Note: the fork system call is called once (in the parent), and returns
twice (in parent and the newly created child)�
1© In the parent process, fork returns P2 (the PID of the child process)
2© In the child process, fork returns 0
P2forkP1
parent child
data data
data data
shared text
parent child
fork()
6= 0 = 0
200
Unix process creation—exec
• Usually, the child then calls the exec system call to run a new program in
the process P2 (the PID does not change)
shared text
parent child
fork()
exec()
Example (start program /usr/X11R6/bin/xclock with parameter
-analog):
exec("/usr/X11R6/bin/xclock", "-analog", 0)
201
Unix process creation—exec
• The child starts to execute the exec’d program (its text) in the new
process
P2forkP1
data data
text
parent
text
exec()’d child
– The child’s parent PID (PPID) is P1
– The resulting process hierarchy can be visualized using pstree:
$ pstree -pu grust
.jws(1232)-+-jws(1269)-+-jterm(1270)---bash(1271)
| |-jterm(1300)---bash(1301)---emacs(1366)
| ‘-jterm(1355)---bash(1356)
‘-wmaker(1263)-+-run-mozilla.sh(1369)---MozillaFirebird(1379)
|-xterm(1675)---bash(1677)---emacs(1707)
‘-xterm(4359)---bash(4361)---pstree(10461)
202
Unix process hierarchy
• Example (use fork from within the Perl debugger)
$ perl -de 1
Loading DB routines from perl5db.pl version 1.19
Editor support available.
[...]
DB<1> print $$."\n"; # PID of this process (1)
15506
DB<2> $child = fork; # fork a new process (2)
DB<3> print "parent: result of fork: ".$child."\n";
parent: result of fork: 15511
DB<4> child: result of fork: 0
child: my parent: 15506
[...]
In forked “Daughter Perl debugger” (getppid returns PPID):
DB<3> print "child: result of fork: ".$child."\n"; # (3)
DB<4> print "child: my parent: ".getppid."\n"; # (4)
DB<5> exec("xcalc"); # (5)
203
Unix process termination—exit and wait
• When the child process has done its work (its program ran until
completion), the program normally invokes the exit system call to
destroy the process
– The child can return a status code to its parent indicating successful
or failed execution:
exit(status)
– The parent can receive the status code by issuing the wait system call:
1© if the child already exited, the wait system call immediately
returns with the status code,
2© if the child is still running, wait waits for the child to exit and only
then lets the parent continue
204
Unix process termination—exit and wait
fork()
exec()
parent
exit(v)wait()
# $? = v
exec()’d child
• Example (fork/exit/wait in the Perl debugger, variable $? contains
status code of child shifted 8 bits left):
$ perl -de 1
[...]
DB<1> $child = fork; # (1)
DB<2> wait; # (2)
DB<3> print "status code: ".($? >> 8)."\n"; # (4)
status code: 42
In forked “Daughter Perl debugger”:
DB<2> exit (42); # (3)
Debugged program terminated. Use q to quit or R to restart, [...]
205
Unix process termination—zombies
• What happens if the child exits before the parent issues a wait to
receive the status code?
– In Unix, the status code is not lost; instead, after the exit the child is
brought into the zombie (or defunct) state
– Although a zombie occurs in the process table, it is not a real process
anymore: only the status code is kept until the parent issues wait
• Example (issue exit in child before wait in parent ⇒ zombie):
DB<1> $child = fork; # (1)
DB<2> wait; # (3)
DB<3> print "status code: ".($? >> 8)."\n"; # (4)
status code: 42
In forked “Daughter Perl debugger”:
DB<2> exit (42); # (2)
Debugged program terminated. Use q to quit or R to restart, [...]
206
Unix process termination—zombies• Process table before step (1):
8721 ? 00:00:00 \_ xterm
8723 pts/11 00:00:00 \_ bash
8733 pts/11 00:00:00 \_ perl # parent
• Process table after step (1), before step (2):
8721 ? 00:00:00 \_ xterm
8723 pts/11 00:00:00 \_ bash
8733 pts/11 00:00:00 \_ perl # parent
9359 pts/11 00:00:00 \_ perl # child
• Process table after step (2), before step (3):
8721 ? 00:00:00 \_ xterm
8723 pts/11 00:00:00 \_ bash
8733 pts/11 00:00:00 \_ perl # parent
9359 pts/11 00:00:00 \_ perl <defunct> # child
• Process table after step (3):
8721 ? 00:00:00 \_ xterm
8723 pts/11 00:00:00 \_ bash
8733 pts/11 00:00:00 \_ perl # parent
207
Unix process creation—Quiz
• Quiz: Explain what happens inside the Unix shell bash when you execute
the following two series of commands:
1© $ xcalc { shell prompt blocked until application xcalc closed }
$ echo $?
0
$
2© $ xcalc &
[1] 16539 { shell prompt returns immediately }
$ echo $!
16539
{ application xcalc closed }
[1] Done xcalc
$
208
Process Scheduling
6.2 Process Scheduling
• Time-sharing (multiple processes run on a
single CPU) maximizes CPU utilization:
– while a process is waiting for I/O to
complete, a different process in the ready
queue is scheduled for execution
– typically, processes alternate between
bursts of CPU and I/O time
– A distribution chart of CPU burst times
shows that the typical CPU burst is short
209
Distribution of CPU burst times
210
CPU scheduler
• Selecting a process in the ready queue is done by the CPU scheduler
(the ready queue is generally not operated in a first-come-first-serve
(FCFS) fashion)
– The following four types of events concern the CPU scheduler:
1© A process switches state: running → waiting (e.g., I/O request,
wait system call)
2© A process switches state: running → ready (e.g., interrupt occurs,
time slice exhausted)
3© A process switches state: waiting → ready (e.g., I/O completed)
4© A process terminates
• A CPU scheduler is called preemptive if 1©– 4© lead to new scheduling
decisions, the scheduler is non-preemptive if only 1© and 4© influence
scheduling
211
Scheduling criteria
• CPU scheduling algorithms try to optimize the scheduling decisions
based on the following criteria:
– maximize CPU utilization
(avoid idle times for the CPU)
– maximize throughput
(maximize # of processes completing execution in a given time frame)
– minimize waiting time
(minimize overall time a process spends in the ready queue)
– minimize response time
(in time-sharing/interactive OSs: minimize time before a process runs
the first time after it enters the ready queue)
212
FCFS scheduling
• First come, first serve (FCFS): the order in which processes enter the
ready queue determines their execution order on the CPU
Example: three processes P1, P2, P3 arrive in this order at time 0:
Process Burst time (ms)P1 24P2 3P3 3
The CPU utilization diagram looks as follows (Gantt chart):
213
FCFS scheduling
• Waiting time for the three processes:
Process Waiting time (ms)P1 0P2 24P3 27
⇒ Average waiting time:
0 ms + 24 ms + 27 ms
3= 17 ms
214
FCFS scheduling
• Now suppose the three processes arrive in the order P2, P3, P1
Gantt chart:
Waiting times:
Process Waiting time (ms)P2 0P3 3P1 6
⇒ Average waiting time: 3 ms
• Under FCFS, average waiting time not optimal, waiting time varies
substantially if process CPU burst times vary greatly
215
SJF scheduling• Shortest job first (SJF): the process with the shortest next CPU burst
time in the ready queue is scheduled for execution (tie: use FCFS)
Example: processes P1, . . . , P4 arrive at the given times with these next
CPU burst times:
Process Arrival time (ms) Burst time (ms)P1 0 7P2 2 4P3 4 1P4 5 4
Gantt chart:
Average waiting time:
0 ms + 6 ms + 3 ms + 7 ms
4= 4 ms
216
Preemptive SJF scheduling
• Preemptive SJF: if a process arrives with burst time less than remaining
burst time of currently running process, preempt
Example: processes P1, . . . , P4 with arrival and burst times as before:
Process Arrival time (ms) Burst time (ms)P1 0 7P2 2 4P3 4 1P4 5 4
Preemptive SJF Gantt chart:
Average waiting time:
9 ms + 1 ms + 0 ms + 2 ms
4= 3 ms
217
Predicting the next CPU burst time
• The SJF idea gives provably minimal average waiting times but is
based on foretelling the future: we need to know the next CPU burst time
of all processes
• The best we can do is to predict the next CPU burst time by looking at
the history
– Exponential averaging:� tn: actual length of most recent CPU burst (at time n, measured)� τn: estimation of CPU burst at time n� 0 6 α 6 1: weighting factor
τn+1 = α× tn + (1− α)× τn
218
Exponential averaging
τn+1 = α× tn + (1− α)× τn
• Weighting factor determines the importance of recent past and history:
– α = 0 ⇒ τn+1 = τn
recent past ignored (current conditions assumed to be temporary)
– α = 1 ⇒ τn+1 = tn
recent past most important (history assumed to be old and irrelevant)
– Common: α = 12
• Expand eponential averaging formula (τ0: system-defined constant):
τn+1 = α× tn + (1− α)× τn
= α× tn + (1− α)×(α× tn−1 + (1− α)× τn−1
)= . . .
= α× tn + · · ·+ (1− α)j × α× tn−j + · · ·+ (1− α)n+1 × τ0
219
Exponential averaging (α = 12)
CPU burst ti Prediction τi10
6 84 66 64 513 913 1113 12
