Scheduling using priorities

n Attach priority to every process

A. Scheduling Wrap-up n Run process with highest priority

B. Memory Management
n Decay priority as a process gets a time quantum
n New Priority = Old Priority * decay-factor

Arvind Krishnamurthy n Increase priority of a process as a process stays idle

New Priority = Old Priority * gain-factor
Spring 2001
n

n Perform these operations after every time quantum

n Question: suppose you have three processes that need to use the
processor in the ratio 3:2:1, how do you setup the priority adjustment?

Lottery Scheduling Memory Management

n Each process owns a certain number of tickets To support multiprogramming, we need “Protection”
n Scheduler chooses a random ticket
n Process that has the winning ticket gets processor n Kernel vs. user mode
n If three processes need to use the CPU in the ratio 3:2:1: n How to implement an address space?
n Allocate 300 tickets to p1, 200 tickets to p2, 100 tickets to p3
n Over a period of time, the processes will get to use the CPU in the
ratio 3:2:1 Physical memory Abstraction: virtual memory
n Simple! Power of randomized algorithms. No protection Each program isolated from all
n Other applications: others and from the OS
n Client-server interactions Limited size Illusion of infinite memory
n Priority inversions
n Hierarchy of agents: currency exchange Sharing visible to programs Transparent --- can’t tell if
n Compensation tickets memory is shared
n Heuristic search

OS Organization Uniprogramming (no protection)

n Uniprogramming without protection n Application runs at the same place in physical memory
n load application into low memory
load OS into high memory
n Multiprogramming without protection: linker-loader n

n application can address any physical memory location

n Multiprogrammed OS with protection:

0x000000
n hardware-based approach Application
n address translation (support of address space)

n dual mode operation: kernel vs. user mode Physical

Memory
n software-based approach
n type-safe languages

n software fault isolation Operating

0xFFFFFF System

1
 Multiprogramming Linker-loader Approach
n Multiple programs share physical memory n How the linker-loader works?
n when copying a program into memory, use the linker-loader to n Compiler generates .o file with code starting at location 0.
change the addresses for all load/store/jump instructions n Also record all the relocatable addresses

n Linker (ld in Unix) scans through each .o, changing addresses to

point to where each module goes in larger program
n Loader loads the executable (a.out) to the memory and run
0x000000
Application 1

n Problem of linker-loader --- no protection: bugs in any

Physical 0x200000 program can cause other programs to crash, even OS
Memory Application 2

Operating
n Goal: how to support protection?
0xFFFFFF System

Incorporating Protection Typical OS (HW Approach)

n Goal of protection
n keep user programs from crashing/corrupting OS
n keep user programs from crashing/corrupting each other Application

How is protection implemented? Standard library Bootstrap

System initialization
n Almost all OS today use hardware-based approach Interrupt and exception
n address translation I/O device driver
n dual mode operation: kernel vs. user mode Portable OS Layer Memory management
Kernel/user mode
n Other approaches: software-based solutions Machine-dependent layer switching
Processor management
n type safe languages
n software fault isolation

Address translation (1) Address translation (2)

n Address space: state of an active program
n Hardware translates every memory reference from virtual addresses
to physical addresses
n Software sets up and manages the mapping in the translation box
n Two views of memory
n view from the CPU --- what program sees, virtual memory
n view from memory --- physical memory
n Translation box converts between the two views

virtual physical
address address n Implement protection because there is no way for
Translation Box
CPU
programs to talk about other program’s addresses
(MMU) physical
memory
n How to implement address translation?
n via table lookup (e.g., segmentation, paging …)
Data read or
write

2
 Why dual mode operation ? Dual mode operation
n If application can modify its own translation tables --- then n Goal: want to isolate each address space so its behavior
it can access all of physical memory --- protection is lost! can’t do any harm, except to itself

n Solution: use “dual-mode” operation n how to share CPU between kernel and user programs
n when in the OS, can do anything (kernel-mode) n how do programs interact?
n when in a user program, restricted to only touching that program’s
memory (user-mode) n How does one switch between kernel and user modes
(HW can require CPU to be in kernel-mode to modify address translation table) when the CPU gets shared between the OS and a user
program?
n In Nachos (as well as most OS’s):
OS runs in kernel mode (untranslated addresses)
OS à user (kernel mode à user mode)
n
n
n User programs run in user mode (translated addresses)
n User à OS (user mode à kernel mode)

Kernel à user User à kernel

To run a user program, create a thread to: How does the user program get back into the kernel ?

n Hardware interrupt (involuntarily)

n allocate and initialize address space control block
n timer interrupt, IO interrupt, etc.
n read program off disk and store in memory
n allocate and initialize translation table (point to main n Program exception (involuntarily)
memory) n bus error (bad address --- e.g., unaligned access)
n segmentation fault (out of range address)
n run program (or to return to user level after calling the OS with a system
n page fault (important for providing illusion of infinite memory)
call):
n set machine registers n System call (voluntarily)
n set hardware pointer to translation table n special instruction to jump to a specific OS handler ---just like doing
n set processor status word (from kernel mode to user mode) a procedure call into the OS kernel
n jump to start of program n on MIPS, it is called “OP_SYSCALL”

Issues with system call User à kernel: how to switch

n Can the user program call any routine in the OS ?
n No! only the specific ones that the OS says are ok.
n How to pass arguments on a system call?
n via registers
n write data into user memory, kernel copies into its memory
except: user addresses --- translated
kernel addresses --- untranslated
n main problem: address the kernel sees are not the same
addresses as what the user sees! Solving this issue is a large part of
Assignment 2 in Nachos.
n What if user programs does a system call with bad
arguments? OS must check everything!
n On system call, interrupt exception: HW atomically
n sets processor status to kernel mode
n changes execution stack to an OS kernel stack
n saves current program counter
n jumps to handler routine in OS kernel
n handler saves previous state of any register it uses
n Context switches between programs:
n same as with threads, except
n also save and restore pointer to translation table
n to resume a program: reload registers, change PSL, and jump to
old PC.

3
 Inter-Process Communication Unix: user-kernel interaction
n Inter-address space (inter-process) communication is a n Shell --- user program (not part of the kernel)
kernel service n prompts users to type command
n special system call to copy bytes written by one program to another n does system call to run command
program
n In Nachos, system call to run command is simply “exec”.
But Unix is a bit different
n Models of inter-address space communication:
n Byte stream producer/consumer (Unix pipes connect stdin/stdout) n Unix idea: separate notion of fork and exec
n Message passing (send/receive). Can use this to build remote n fork: create a new process, exact copy of current one
procedure call (RPC) abstraction --- one program calls a procedure n exec: change current process to run different program
in another
n to run a program in Unix
n Shared-memory region. Map part of virtual address space of
n fork a process
different programs to same physical memory
n in child, exec program
n File system (read and write files) is shared state! n in parent, wait for child to finish

User-kernel Interaction Protection without h/w support

n Unix fork: n Put two programs in the same address space and
n stop current process guarantee that they can’t trash each other’s code or data.
create exact copy
Use strongly typed languages, e.g., Java, ML, Lisp, Modula-3
n
n
n put on ready list
n Use software fault isolation
n resume original
Original has code/data/stack. Copy has exactly the same thing
Only difference between child and parent:
n Applications of software protection
n safe downloading of programs onto local machine over Web
n Unix changes one register in child before resume
n safe anonymous remote execution over Web (web server)
n Child process “Exec” program: n plug-ins. Complex application built by multiple vendors (isolate
n stop process failures in plug-in code from killing main application)
n copy new program over current one n Kernel plug-ins. Drop application-specific code into OS kernel to
n resume at location 0 customize its behavior (SPIN at U. Washington)
Justification: share IO tables

Protection via strong typing Software Fault Isolation

n Programs written in type-safe languages can be
downloaded and run safely
n language/compiler/runtime prevents the program (e.g., applet)
from doing anything bad (e.g., if can’t make system calls then it
can’t touch files)
n Language independent approach --- have compiler generate object
code that provably can’t step out of bounds.
n Insert code before each “store” and “indirect branch” instruction ---
check that address is in bounds

n Java defines a portable machine layer --- so any Java programs can store r2, (r1)
run anywhere, dynamically compiled onto native machine
r1:
safeReg <- r1 & segment-mask
Problem: require everyone to learn new language --- any code not in Segment bits
clear segment identifier bits
Java can’t be safely downloaded. safeReg <- safeReg | segment-reg
set segment identifier bits
store r2, (safeReg)