Operating Systems: Introduction 2001 Fall

1
Operating Systems Introduction2001 Fall

• Joonwon Lee

2
Introduction

• Why DO We Study OS?
• 1. to make a better OS
• 2. to understand computer systems better.
• - We are all computer users !!
• 3. the capstone of all the computer science
  principles
• languages, hardware, data structures,
  algorithms. ,,,
• What Do We Study?
• 1. Abstraction
• OS gives us an illusion that there are infinite
  number of CPUs, infinite memory, single world
  wide computing, ....
• 2. System Design
• tradeoffs between performance and simplicity
• functionality either by hardware or by software
• 3. How computers work
• let's look inside of computers
• 4. OS Research

3
What this course is about

• OS Principles - You've learned a lot from a
  textbook
• OS research literature
• history of OS
• current trends in OS research
• understand where these trends come from
• identify interesting research topics
• relate current work to the past
• Conducting OS research
• learn to produce quality research
• identify problem
• design an experimental setup
• building, measuring, analyzing
• practice conducting research (final project)

4
What is OS Research?

• Identification of a problem/phenomenon
• physical memories are small
• CPU is getting faster but IO is NOT that much
• applications change often but OS does NOT
• personal computing is popular
• Hypothesize a solution
• Evaluate the hypothesis
• Measure
• Measure
• Measure again
• Use real system if possible
• gather trace data
• instrument existing systems
• simulation
• analytical investigation
• isolate small components

5

• Draw conclusion
• use result to suggest new hypotheses
• compare results against other's results
• Toughest things
• there are not necessarily any right answers
• no one can tell you with certainty that you are
  right
• you are never done
• large system is difficult to understand

6
Writing a Research Paper

• Abstract
• introduce area (1 sentence)
• state problem/area (1-2 sentences)
• summarize conclusions (be quantitative)
• Introduction
• complete description of problem
• state more detailed results
• short summary of what's have been done
• road map of the paper
• Motivation
• why is this work important
• what horrible things will happen if this work is
  not done
• what good things will happen if this work is done
• why is now the right time to be doing this work

7

• Previous Work
• do a thorough literature search (from 60's)
• neither more nor less list of references
• relate your work to existing work
• demonstrate how your work fits in to the grand
  scheme of things
• What you did
• describe your research
• be thorough, but concise
• The Results
• describe experiment setup
• explain expected results, reasons for such
  expectation
• explain surprising difference
• visual presentation of data
• Conclusions
• state results again
• state significance of results
• tell people what they should have learned

8

• Future Work
• what questions still remain
• what new questions have arisen
• how can your work be extended
• General Tips
• spell-check very important
• grammar-check very difficult for us
• style check passive voice, plular, he/she, ...
• let the paper sit for a few days before proof
  reading
• as research is going on, starts writing
• write early
• write often very important

9
History of OS

• Why Do We Study History?
• 1. Main focus
• Effect of changes in hardware technologies,
  computer usage, and cost on the design of OS
• 2. Hardware changes
• 1980 1995 factor
• MIPS 1 300 300
• cost/MIPS 100K 50 2000
• memory 128KB 64MB 500
• disk 10MB 2GB 200
• network 9600BPS 155MBPS 15000
• address bits 16bits 64bits 4 (24)
• 3. Design a system that can span its life for a
  new technologies

10

• When hardware was very expensive
• batch monitor OS loads, runs a program (Like
  your DOS)
• no protection OS was vulnerable to user program
• multiprogramming
• overlap of IO and computation
• use of DMA
• several programs run simultaneously users shared
  the system
• more overlap between IO and CPU
• protection is required
• OS gets complicated
• Multics, OS360 takes long time to deliver, too
  many bugs
• UNIX works solely due to its simplicity even
  though it is based on Multics

11
History of OS (cont'd)

• When hardware is cheap and humans are expensive
• Interactive timesharing
• Use cheap terminals to let multiple users
  interact with the system at the same time.
  Sacrifice CPU time to get better response time
  for users.
• Personal computing
• Computers are cheap, so give everyone a
  computer. Initially, OS became subroutine library
  again, but since then, have added back in memory
  protection, multiprogramming, ..etc.
• Lessons you have to learn
• Batch processing is not stupid. It was right for
  the tradeoffs at the time - but not anymore
• Have to change with changing technologies
• Situation today is much like it was in the late
  60's OS's of today are enormous, complex.
• Why OS's are getting complex?
• intelligence show off
• market demands more features
• Avoid complexity

12
OS Overview

• What is an OS
• all the code that you didn't write
• the code that manages physical (hardware)
  resources
• provides users with "logical" well-behaved
  environment
• OS defines a set of logical resources and a set
  of well-defined operations on those objects
  (interfaces)
• provides mechanisms and policies for the control
  of objets/resources
• controls how different users and programs
  interact
• Resources managed by an OS
• CPU
• memory
• disk
• networks
• keyboard, mouse
• various IO devices printers, speakers, cameras.
  ...

13
OS Overview

• Major Issues in OS's
• structure how is an OS organized?
• sharing how are resources shared among users?
• naming how are resources named by users or
  programs
• protection how is one user/program protected
  from another
• security how to restrict the flow of information
• performance why is it so slow?
• reliability and fault tolerance when something
  goes wrong
• extensibility how do we add new features?
• communication how and with whom can we
  communicate (exchange information)
• concurrency how are parallel activities created
  and controlled?
• scale and growth what happens as demands or
  resources increase?
• persistency how to make data last longer than
  programs
• compatibility can we ever do anything new?
• distribution accessing the world of information
• accounting who pays the bill?

14
OS Overview

• Multiprogramming OS
• keeps multiple runnable programs loaded in the
  memory
• overlaps IO processing of a job with computing of
  another
• benefits from asynchronous IO devices
• needs mechanism of interrupts and DMA
• tries to optimizes throughput, not response time
• Timesharing
• each user feels as if she has the entire machine
• timesharing tries to optimize response time, not
  throughput
• needs mechanism of of time-slicing of CPU
• timer clock
• scheduler
• users are permitted to control of the execution
  of process
• Multics(MIT) was the first large timesharing OS

15
OS Overview

• Real Time OS
• used for specialized applications
• subway systems, flight control, factory
  automation, nuclear power plant, and multimedia
• basic idea OS guarantees response to physical
  events in a fixed time interval
• problem how to schedule all the activities in
  order to meet all of their critical requirements
• with the advent of multimedia applications, all
  the OS's will soon see real time needs
• Distributed OS
• controls facilities distributed geographically
• supports communication between parts of jobs or
  different jobs
• controls sharing of resources
• permits parallel processing, but speedup is not
  the issue

16

• Parallel OS
• runs on various multiprocessor systems
• supports parallel applications wishing to get
  speedup
• needs mechanism to control parallelism
• how to divide one task into multiple tasks that
  can run in parallel
• how to support communications between those
  subtasks
• how to synchronize the activities of those
  subtasks
• have to cope with variety in hardware
  technologies
• inter-processor communication
• routing chips or interconnection network
• shared memory or message passing

17
Architectural Support for OS

• OS and Architecture
• the functionality of an OS is limited by
  architecture features
• the structure of an OS can be simplified by
  architectural support
• DOS is so primitive due to the lack of hardware
  support when it was first designed
• Most proprietary OS's were developed with the
  architecture
• Architectural features for modern OS
• timer operation
• atomic synchronization operations
• memory protection, fast address translation (TLB)
• IO control and operations (DMA, IOP)
• interrupts and exceptions
• OS protection (kernel/user mode)
• protected instructions
• system calls
• partial completion of an instruction

18
System Protection

• Protected Instructions
• users should not be allowed direct access to
• IO devices such as disks, printers, ...
• use privileged instructions or memory mapping
• memory management states
• page table updates,
• page table pointers
• TLB loads, flush, ...
• setting special mode bits
• halt instruction (why do we need this?)
• OS Protection
• how do we know if we can execute a protected
  instruction?
• architecture must support at least two modes of
  operations kernel and user
• mode is indicated by a status bit in a protected
  processor register
• user program executes in used mode the OS
  executes in kernel mode
• protected instructions can only be executed in
  kernel mode.

19
Crossing Protection Boundaries syscall

• users have to ask OS to do something privileged
  in behalf of them
• how does a user program call a kernel mode
  service?
• system call
• system call instructions should be available to
  users
• required features of a system call
• stop what is going on exceptions
• specifies the kind of service asked interrupt
  vector
• specifies the exact contents of the action
  parameter passing
• saves the status of what is going on so it can be
  restored when the service is done
• there must be a way to return to user mode

user program
user mode
system call
kernel mode
trap to kernel mode
trap handler
system service routine
OS kernel
20
Memory Protection

• OS must protect user programs from each other
• must protect OS from user programs
• may or may not protect user programs from OS
• a simple protection
• base and limit registers are loaded by the OS
  before the starting of a program
• paged virtual memory system or segmented memory
  system adopt similar scheme.

prog A
base register
prog C
limit register
prog B
21
Exception

• hardware must detect special conditions
• page fault, write to read-only page, overflow,
  ...
• must transfer control to OS immediately
• hardware must save state of the running process,
  so that the faulting process can be restarted
  afterwards
• what if there is no hardware support
• OS should keep checking the condition at a very
  high cost

22
Synchronization

• interrupts cause potential problem because an
  interrupt can occur at any time
  non-deterministic race condition
• concurrent processes may interfere with each
  other
• needs an atomic operation at various level
• primitive one (test and set) by hardware
• software can do this at a high cost
• some by programming languages
• then, why do we study this in OS courses
• OS contains lots of concurrency in itself
• synchronization sometimes involves process
  management

23
IO Control
device interrupts

• IO Control
• IO issues
• how to start IO operation
• IO completion interrupts
• interrupts and asynchronous IO

CPU stops current operation, switches to kernel
mode, and saves current PC and other states on
kernel stack
CPU fetches proper vector from vector table and
b ranches to that address (to interrupt handler)
interrupt routine examines device database
and performs actions required by the interrupt
handler completes operation, restores saved
(interrupted) state and returns to user mode (or
calls scheduler to switch to another program)
24
Timer

• how does OS prevent infinite loops?
• a timer is set to generates an interrupt in a
  given time
• before a user process begins, OS loads the timer
  with a time to interrupt (more primitive hardware
  generates interrupts periodically independent of
  OS)
• when the time arrives, the timer issues an
  interrupt, and thus the user program stops and OS
  regains control

25
OS Structure and Components

• Process Management
• a process
• execution entity
• includes an execution context
• an instance of a program in execution (program is
  only a file on the disk that is potentially
  runnable)
• many processes exists
• user programs
• batch jobs
• print spooler, name server, network listener
• OS schedules these processes

code stack PC registers
page tables resource counts .......
26
OS Structure and Components

• Memory Management
• primary memory is the space that is directly
  accessible from CPU
• program should be in memory to execute
• OS must
• allocate space for programs to run
• deallocates space when needed
• mapping virtual to real address (when virtual
  memory is used)
• decides how much space to allocate to a process,
  and when a process should be removed from memory
• IO Management
• much of OS kernel is concerned with IO
• OS provides a standard interface between devices
  and programs (user or OS)
• need a device driver for each device type
• device driver encapsulates device-specific
  knowledge, i.e., device commands, device status,
  data format, errors, ..

27
OS Structure and Components

• Disk Management
• disk is the persistent memory, i.e., it endures
  system failures (we wish)
• OS does
• scheduling of disk requests
• disk arm movement
• error handling
• the line between this and the file system is very
  fuzzy
• File System
• raw disk is too crude to be used by user programs
  (even for OS)
• the file system provides logical objects and
  logical operations on those objects
• a file is the basic long-term storage entity a
  file is a named collection of persistent
  information that can be read or written
• needs a way to locate information about a file
  efficiently
• a directory may be itself a file
• file system provides standard file operations
• the file system also provides general services,
  e.g.
• backup
• maintaining mapping information
• accounting and quotas

28
OS Structure and Components

• Protection System
• when many processes may rub concurrently, all
  resource objects need protection
• memory
• processes
• files
• devices
• protection mechanism helps to detect errors as
  well as to prevent malicious destruction
• Command Interpreter
• interprets user command issued from a keyboard
• some systems have it as a standard part of OS
• other systems it is just a user program
  (replaceable)
• others do not have such thing they have iconic
  interface
• Accounting System
• keep track of resource usage
• used for enforce quotas, or to generate bills

29
OS Structure

• So far, you have seen components of an OS
• the issues are
• how to organize all of them
• what are the entities and where are they
• how do these entities cooperate
• in reality,
• interaction between these components is very
  complex
• boundaries between them are very fuzzy
• but, we have to build an OS that is
• working
• efficient (performance)
• reliable
• extensible

30
Traditional Structure

• everything in one process monolithic kernel
• why monolithic?
• that's the way we lived
• fast interaction between components (procedure
  call)
• easy sharing no protection between OS components
• why not monolithic?
• hard to understand
• hard to modify
• unreliable a bug in anywhere causes an entire
  system crash
• hard to maintain

31
Layered Structure

• it has been used in structuring many complex
  systems
• a layer is a virtual machine to the layer above
  it
• a layer should not be aware of a layer above it
• THE (Dijkstra)
• why layering?
• easy to focus on a small task
• easy to build a large system step by step
• why not layering?
• real systems are more complex than a simple
  hierarchy
• not flexible
• poor performance sue to layer crossing
• In real world, systems are often modelled as
  layered structures but not built that way

32
Microkernel architecture

• a structure in vogue
• minimize that goes in the kernel
• implement the remaining things of OS as
  user-level processes
• what for?
• better reliability (focus on small part)
• ease of extension and customization
• any problem? poor performance
• interaction between OS components is not
  procedure call anymore, it is inter-process
  communication
• Examples
• Hydra (CMU, 1970)
• MINIX (Tannenbaum)
• CMU March IBM Workplace, OSF/1. ...
• Chorus
• Microsoft Windows/NT (in a way)

33
Processes

• Related OS functions
• Coordinator
• allow several things to work together in
  efficient and fair ways (examples concurrency,
  memory protection, file systems, ..)
• Standard devices
• provide standard facilities that everyone needs
• (examples standard libraries, windowing
  systems, ..)
• Concurrency
• OS has to coordinates all the activities on a
  machine multiple users, IO activities, etc.
• How can it keep all these thing straight?
• Answer
• Decompose hard problems into simpler ones.
  Instead of dealing with everything going on at
  once, separate them so that we can deal with one
  at a time.
• What is a Process?
• OS abstraction to represent what is needed to run
  a single program (UNIX definition)
• A sequential stream of execution in its own
  address space (formal definition)

34
Processes

• Issues
• what are the units of execution?
• how are those units of execution represented in
  the OS?
• how is the work scheduled on the CPU?
• what are possible execution states, and how does
  the system move from one to another?
• What's in a process?
• the code for the running program
• the data for the running program
• an execution stack (for procedure calls)
• the program counter indicating the location in
  code to execute
• a set of registers with current values
• a set of OS resources that the process uses
• open files, connections to other programs, ..
• Process and Programs
• There may be many processes running the same
  program (Examples vi, cc, ...)
• There may be many programs run by a single
  process
• (Examples cc runs several programs such as cpp,
  cc1, cc2, ..)

35
Processes

• Process State
• Each process has an execution state that
  indicates what it's currently doing
• ready waiting for CPU allocation
• running execution instructions on the CPU
• waiting waiting for an event such as IO
  completion
• As a program executes, the process moves from
  state to state
• Actions that trigger transition of states
• system calls (by itself)
• OS rescheduling (by timer interrupt)
• interrupts (by external events)

created
scheduler
ready
running
sys call
blocked
terminated
36
Processes

• Data Structure for a Process
• represents the state of a process
• stored in Process Control Block and other area
  (u-, u. area)
• PCB is accessed by kernel
• PCB contains information for OS to manage this
  process
• process state
• process number
• hardware context (PC, registers, SP)
• memory management information
• list of open files
• queue pointers to state queues
• scheduling information (priority, real -time QOS,
  ..)
• accounting information
• IO states, IO in progress
• .....etc

37

• some information is in u-area
• mapped to the virtual address space of the
  process
• u-area may be swapped out
• u-area may be readable in user mode
• difficult for OS to locate information in u-area
• u., u-area contains information for executing
  this process
• user/kernel mode state
• state related to system calls
• descriptor table
• the per-process execution stack for the kernel
• resource control (of those that do not need OS
  coordination)

38
Processes

• Context Switching
• happens on timer interrupt, IO request, ..
• saves the hardware context in the running PCB
• finds a process to run next
• loads the values in PCB onto the hardware
  registers
• time quantum 1 10 ms
• State queues
• the OS maintains a collection of queues that
  represent the state of all processes in the
  system.
• there is typically one queue for each state
• ready, blocked for IO, sleep, wait for signal,
  ....
• there may be many wait queues, one for each type
  of wait

ready Q
PCB A
PCB Z
PCB G
sleep Q
PCB C
PCB B
IO Q
PCB R
PCB M
PCB N
39
Processes

• PCBs and state queues
• PCB is a data structure allocated by OS
• PCB is allocated when a process is created
• PCB moves from one state queue to another state
  queue as the computation goes on
• when a process terminates, the PCB is deallocated
• Creating a Process
• one process can create other processes. These are
  child processes and the creator is the parent
• the parent usually donates resources and
  privileges for its children
• a parent may proceeds with its child in parallel
• fork()
• the child inherits everything from the parent
  except for a return code
• needs exec() to execute a new program

40
Address Space

• What is it?
• a range of addresses a thread can access
• consists of code, data, heap, stack
• How large is it?
• the larger the better
• with 32 address bits, total 4.3 giga bytes
• do we really need all this space?
• single address space
• OS partitions the total space into many smaller
  ones, and allocates each partition to a process
• each process uses unique range
• need protection mechanism
• multiple address spaces
• OS maintains multiple spaces of the same range,
  e.g., each process is allocated the same
  04.3giga space
• each process needs a unique mapping from the
  address space to real storage

41
Threads

• A Full Process includes
• an address space defining all the code and data
  pages
• OS resource and accounting information
• a thread of control which defines where the
  process is currently executing (PC and registers)
• Creating a process is expensive due to all of the
  structures (e.g., page tables) that must be
  allocated
• Communicating between processes is costly,
  because most communication goes through the OS
  (remember the steps needed to cross protection
  boundaries)
• Needs for a large number of processes
• parallel processing (per parallelism)
• large server (per requests)
• constructing a large complex system

42
ThreadsThe Thread Model (1)

• (a) Three processes each with one thread
• (b) One process with three threads

43
The Thread Model (2)

• Items shared by all threads in a process
• Items private to each thread

44
The Thread Model (3)

• Each thread has its own stack

45
Thread Usage (1)

• A word processor with three threads

46
Thread Usage (2)

• A multithreaded Web server

47
Thread Usage (3)

• (a) Dispatcher thread
• (b) Worker thread

48
Thread Usage (4)

• Three ways to construct a server

49
Implementing Threads in User Space

• A user-level threads package

50
User Level Thread

• User-Level Threads
• to run faster, threads must be in user-level
• a user-level thread is managed entirely by the
  run-time system
• each thread is represented by ..... that is in
  user space
• all the services related to threads are executed
  in user level without kernel involvement
• Performance Comparisons
• in microseconds
• measured on old 3 MIPS hardware

Ultrix
Topaz
FastThreads
fork()
11320
1208
39
signal/wait
1846
229
52
51
User Level Thread 2

• User-Level Threads
• much faster than kernel threads
• lacks in integration with OS
• running a process that has no work to do
• block a process even when there is a thread ready
  to run
• remove a process whose thread holds a lock
• Solution communication between the kernel and
  the user-level thread package
• Threads in Solaris 2.x

user thread
kernel thread
CPU
CPU
CPU
52
Implementing Threads in the Kernel

• A threads package managed by the kernel

53
Kernel Threads

• kernel is aware of the existence of threads
• kernel manages threads like processes
• slow, because of
• a thread operation still requires a kernel call
• kernel threads are overly general, in order to
  support all the user needs
• the kernel does not trust the user, so there must
  be lots of checking on kernel calls.

54
How different OSs support threads
address space
thread
Unix
MS/DOS
Xerox/Pilot
Mach, Chorus, NT Solaris, HP/UX
55
Scheduler Activations

• Goal mimic functionality of kernel threads
• gain performance of user space threads
• Avoids unnecessary user/kernel transitions
• Kernel assigns virtual processors to each process
• lets runtime system allocate threads to
  processors
• Problem Fundamental reliance on kernel
  (lower layer)
• calling procedures in user space (higher
  layer)

56
Pop-Up Threads

• Creation of a new thread when message arrives
• (a) before message arrives
• (b) after message arrives

57
Threads - Summary

• Why NOT Kernel Threads?
• semantic inflexibility
• users want different notion of threads - run
  time behavior, scheduling, number of threads
• poor performance
• Why NOT User-Level Threads
• blocking system call
• lack of coordination between synchronization and
  scheduling
• lack of convention for sharing among thread
  packages

58
Memory Management

• What to manage
• size illusion of infinite memory
• protection protect program and OS
• sharing let programs share code, data
• Protection
• address space
• all the addresses a program can touch
• all the state that a program affect or be
  affected by
• MMU translates address generated from CPU
• restrict what a program can touch
• Dual mode
• in kernel mode, can do anything (untranslated)
• in user mode, can touch only its own address
  space (translated)
• how a control transfers from kernel to user

59
Address Translation

• Address translation without HW support
• uniprogramming (DOS)
• OS resides in a fixed location (high memory)
• load user program in a fixed location (low
  memory)
• user program can touch anywhere even an OS
• multiprogramming can multiple programs run
  without HW support?
• yes, by relocating addresses used by load,
  store, jump
• this is done by linker-loader
• still no protection
• Hardware Translation

Translation Box (MMU)
real address
Physical Memory
virtual address
CPU
untranslated
60
Base and Bounds

• base and bounds
• each program is loaded into contiguous region of
  physical memory but with protection (Cray-1)
• program has illusion that it has its own machine
• address from CPU is added with base to form a
  real address
• address from CPU is checked to see if it is
  within bound
• only OS can change the base and bounds
• hardware cost
• 2 registers
• adder and comparator
• performance loss
• time to add/compare on every memory reference
• cons
• difficult to share
• hard to grow address space
• complex memory allocation (first fit, best fit,
  buddy system)

61
Segmentation

• Solutions to the above 3 problems of base
  bounds
• segmentation sharing and resizing
• paging sharing and memory allocation
• paged segmentation all of them
• Segmentation
• a table of base and bounds
• virtual address table
  physical
• there are holes in virtual addresses
• correct program would not touch that holes
• if it does, trap to kernel. OS will take care of
  it
• pros and cons
• efficient for sparse spaces

code
stack
data
data
stack
code
62
Paging

• Paging
• eases memory allocation problem
• virtual memory and physical memory are divided
  into many chunks of the same size page
• page table maps virtual page number into physical
  page number
• what if the size of page is very large
• internal fragmentation
• what if the reverse
• lots of space for page table
• pros and cons
• simple memory allocation
• easy to share
• - big page table if sparse address space

63

• Multi-Level Translation
• use tree of tables
• segmentation paging
• virtual address consists of ltseg , page,
  offsetgt
• seg indexes into the seg table to find the
  address of page table
• page indexes into the page table to find the
  physical page number
• pure multilevel paging
• same
• Where is the page table
• in virtual address space (I said it may be LARGE)
• how to translate the address for the page table
  (recursion)
• keep the page tables for the page tables in
  memory
• in seg paging, seg tables contains virtual
  address for some segments and real address for
  some others (HP, MIPS)

64
TLB

• address translation needs three memory references
• system page table
• user page table
• for real data
• solution use cache
• Cache
• copy that can accessed more quickly than original
• idea make frequent case efficient, infrequent
  paths do not matter as much
• generic issues in caching
• hithow do you know if it is a hit?
• miss how do you choose what to replace to make a
  room?
• consistency

65

• Memory Hierarchy
• principles
• the smaller the faster
• the larger, the cheaper per unit
• latency size cost
• registers 5ns 32-128B on chip
• on-chip cache 10ns 4KB on chip
• off-chip cache 25ns 64KB 5000/MB
• main memory 200ns 64MB 50/MB
• disk 10Mns 2GB 0.5/MB
• use cacheing at each level, to provide illusion
  of gigabytes at register speed

66
TLB

• Cacheing in Address Translation
• cache recent address translation
• TLB (Translation Lookaside Buffer)
• hardware table
• ltvirtual page number, real page number, control
  datagt
• how do we know if it is a hit
• direct mapped
• set-associative
• fully-associative
• TLB is usually fully associative since it is
  small
• why is it smaller than memory caches even when it
  is referenced at the same frequency?
• What to replace?
• random since hardware is dumb
• LRU if traps to OS (OS is slow)

67

• Consistency
• context switch
• invalidate all the TLB entries
• tag process id
• when translation information changes
• by paging
• invalidate corresponding TLB entry
• multiprocessor
• each node has its own TLB
• problem sources
• process migrates back and forth
• threads share a TLB even when they run on
  different processors
• processes share some pages
• shoot-down algorithm (Mach)
• stall processors to invalidate all the TLBs
• with some hardware, selective invalidation is
  possible (ask Intel)

68
Issues with 64-bit Address Spaces

• Problems
• page table is huge for 64-bit address space
• inverted page table is not a solution due to
  increased physical memory size
• most programs use the address space sparsely
• Multi-level page tables
• PTEs are structured into an n-ary tree
• reduces significantly PTEs for unused address
  space
• when the height of the tree is large
• too many memory reference to find a PTE
• when it is too small
• lose the benefit of multi-level

69

• Hashed page tables
• hash function maps a VPN to a bucket
• a bucket is a linked list of elements which
  consist of
• PTE (PPN, attribute, valid bit,..)
• VPN (almost 8 bytes)
• next pointer (8 bytes)
• space overhead 16 bytes per PTE
• next pointer can be eliminated by allocating a
  fixed number of elements for each bucket
• overflow problem remains
• Clustered page table
• each element of the linked list maps multiple
  pages
• VPN
• next pointer
• n PTEs
• a memory object (in virtual address) usually
  occupies multiple pages
• space overhead of the hashed page table is
  amortized
• more efficient than linear table for sparse space

70
A New Page Table for 64-bit Address Spaces

• Can this scheme support new TLB technologies such
  as superpage and subblocking?
• Superpage
• translation of a superpage
• a superpage is 2n of base page size
• each TLB entry must has the size field
• reduce TLB misses since each entry maps wider
  region
• good for
• frame buffer
• kernel data
• DB buffer pool
• how about file cache?
• Subblocking
• put multiple PPNs in a TLB entry
• it may waste TLB space
• partial subblocking
• physical memory is aligned, so
• one PPN in a TLB entry
• multiple valid bits needed

71
Demand Paging

• 90-10 rule
• Programs spend 90 of their time in 10 of their
  code
• use main memory as a cache for disk
• some pages are in memory
• some are on disk
• Transparency
• user programs should not know paging
• restartability hardware must help out by saving
• faulting instruction
• processor state
• problems
• side effects of CICS
• delayed branches filled with previous instruction
• 1234(br to X)56 gt 34(br to X)1256
• if page faults after br, the saved return address
  will be X, and instructions 1,2 will remain
  unexecuted
• delayed loads
• what if fault occurs while previous loads are
  still in progress
• MVL

72

• Replacement Policies
• Optimal
• random
• FIFO
• LRU (least recently used)
• LFU (least frequently used)
• use Huffman code
• Belady's anomaly FIFO

73
Demand Paging

• Implementing LRU
• Perfect
• keep ordered list of all the pages
• clock algorithm
• pages form a circle and a hand points a page
• use bit of a page is set on each reference
• on page fault, OS advances hand
• if the use bit is set, clear the use bit (loop
  until a page with the use bit clear is found)
• replace this page (whose use bit is not set)
• partitions pages into young and old
• why not k partitions? how?
• read undergraduate textbook for more algorithms

74
Demand Paging

• Modeling
• terminology
• reference string r list of accessed pages
• memory state M
• pages in memory (m) pages on disk (n-m)
• stack page accessed last is at the top
• distance string
• distance from the top of M for a page accessed
• probability density function (PDF)indicates how
  many faults will occur for a given size of memory

number of page faults when main memory has k
pages
PDF
k
distance string
75

• Working set
• a set of pages a process accesses during a time
  interval
• if memory cannot accommodate the working set
  there will be thrashing
• keeping the working set in main memory is crucial
  to good performance
• Issues
• address space consists of code, data, stack, heap
• same policy for all these objects?