What to do when not enough

memory?
n Thrashing: processes on system require more memory than it has.

P3
Thrashing & Disk I/O P1 P2

Real mem
n Each time one page is brought in, another page, whose contents will
Arvind Krishnamurthy soon be referenced, is thrown out.
n Processes will spend all of their time blocked, waiting for pages to be
Spring 2001 fetched from disk
n I/O devs at 100% utilization but system not getting much useful

work done
n What we wanted: virtual memory the size of disk with access time
of of physical memory
n What we have: memory with access time = disk access

Examples Page Fault Behaviour

n Process refers to the following pages:
123451234512345
n Physical memory size: 5 pages, 100% hit rate
n Physical memory size: 4 pages, 0% hit rate
Page Faults

n Irrespective of whether the replacement is FIFO or LRU

n If reference string is:
12345543212345543
n If reference is uniformly distributed amongst 5 pages, what
is the hit rate?
n Requires some probability based calculations
n Bottomline:
n Above a certain threshold, processes behave well Number of page frames
n Below a certain threshold, hit-rate becomes very low

Page Fault Behaviour Multiprogramming Revisited

n For a fixed physical memory size n Goal:
n Each user gets his/her own machine
n Also improve CPU utilization
Compute Compute
Hit Rate

CPU Util.

Program size

Multiprogramming

1
 Including Page Fault Behavior
n One way to characterize execution:
n Number of cycles before the next page fault (n) given physical
memory size (m)
n Cost of page fault in cycles (p)
n CPU Utilization of 1 process = n/p
n When you run more processes, say 2:
n CPU utilization (ideally) = 2*n/p
Thrashing
n Process(es) “frequently”reference page not in memory
n Spend more time waiting for I/O then getting work done
n Three different reasons
n process doesn’t reuse memory, so caching doesn’t work
n process does reuse memory, but it does not “fit”

n But number of cycles before the next page fault decreases since
P1
both processes are sharing m mem
n CPU utilization < 2*n/p
n individually, all processes fit and reuse memory, but too many for
n CPU utilization = multiprogramming * page fault behavior system.
n At some point, incremental increase in multiprogramming is less n Which can we actually solve?
than incremental decrease in locality of page access

Making the best of a bad

When does thrashing happen? situation
n (Over-)simple calculation of average access time: n Single process thrashing?
n If process does not fit or does not reuse memory, OS can do
nothing!
Let h = percentage of references to pages in memory
Then average access time is
h * (cost of memory access) n System thrashing?
+ (1-h) * (cost of disk access)
For current technology, this becomes (about) n If thrashing arises because of the sum of several processes then
h * (0.3 microseconds) + (1-h) * (10 milliseconds) adapt:
Assume 1 out of 100 references misses. n figure out how much memory each process needs

= .99 * (300 ns) + .01 (10ms) n change scheduling priorities to run processes in groups whose
= .99 (300 ns) + .01 (10,000,000ns)
memory needs can be satisfied (shedding load)
= 297 + 100,000 ~ 100 microseconds
n if new processes try to start, can refuse (admission control)
n or, 300x slower than main memory.
n Even small miss rates lead to unacceptable average access
times. Can OS help?

Methodology for solving? Working set (1968, Denning)

n Approach 1: working set
n thrashing viewed from a caching perspective
n given locality of reference, how big a cache does the process need?
n Or: how much memory does process need in order to make
“reasonable” progress (its working set)?
n Only run processes whose memory requirements can be satisfied.
n Approach 2: page fault frequency
n thrashing viewed as poor ratio of fetch to work
n PFF = page faults / instructions executed
n if PFF rises above threshold, process needs more memory
n not enough memory on the system? Swap out.
n if PFF sinks below threshold, memory can be taken away
n What we want to know: collection of pages process must
have in order to avoid thrashing
n This requires knowing the future.
n Working set:
n pages referenced by process in last T seconds of execution
considered to comprise its working set
n T: the working set parameter
n Uses?
n Page replacement: preferentially discard non-working set pages
n Scheduling: process not executed unless working set in main
memory

2
 Scheduling: the balance set How to implement working set?
n If sum of working sets of all runnable processes fits in memory, then n Associate an idle time with each page frame
scheduling same as before. n idle time = amount of CPU time received by process since last
n If they do not fit, then refuse to run some access to page
n How? n page’s idle time > T? page not part of working set
n Divide into two groups:
n active: working set loaded

n inactive: working set intentionally not loaded

n How to calculate?
n balance set: sum of working sets of all active processes n Scan all resident pages of a process
n use bit on? clear page’s idle time, clear use bit
n Long term scheduler:
n Keep moving processes from active à inactive until balance set less n use bit off? add process CPU time (since last scan) to idle time

than memory size. n Unix:

n Must allow inactive to become active. What happens if this changes too n scan happens every few seconds
frequently?
n T on order of a minute or more
n As working set changes, must update balance set…

Some problems Working sets of real programs

n T is magic (or “voodoo constant”)
n what if T too small? Too large?
Working set size

n How did we pick it? Usually “try and see”

n Fortunately, systems aren’t too sensitive
n What processes should be in the balance set?
n Large ones so that they exit faster?
n Small ones since more can run at once?
n How do we compute working set for shared pages?
n How much memory is needed in order to keep CPU busy?

n Typical programs have phases: transition, stable

n working set of one may have little to do with other
n balloons during transitions

Working set less important Virtual memory: a summary

n The concept is a good perspective on system behavior. n Goal: multiprogramming with protection + illusion of
As a technique for system optimization it’s less important
n
infinite memory
n While early time sharing systems thrashed distressingly often,
current systems much less so. n Approaches
HW-based solution for protection
n Have OS designers gotten smarter? No. It’s the hardware n

n dual mode operation + address space

guys:
n address translation: virtual address à physical address
n Memory much larger (more to go around)
n segmentation + paging + multilevel paging
n CPU faster (jobs exit quicker, return memory to freelist)
n making address translation faster? use TLB
n While some applications can eat as much as you give, the
percentage of them that have “enough” seems to be increasing. n demand paged virtual memory
n These will also show up as big factors for file systems n techniques for dealing with thrashing
n More generally, while performance was very important OS

research topic in 80-90s, less so now

3
 Disk organization More on disks
n Disk surface n CD’s and floppies come
n Circular disk coated with individually, but magnetic
magnetic material disks come organized in a
n Tracks disk pack
n Concentric rings around disk
surface, bits laid out serially
along each track
n Cylinder
Certain track of the platter
Sectors
n
n

n Each track is split into arc of seek a cylinder

track (min unit of transfer) sector n Disk arm
n Seek the right cylinder

Disk performance Disk behaviors

% of Disk
Block Size
n Seek There are more sectors on Transfer
n (Kbytes)
n Position heads over cylinder, typically 5.3 − 8 ms outer tracks than inner Bandwidth
n Rotational delay tracks
1Kbytes 0.5%
n Wait for a sector to rotate underneath the heads n Read outer tracks:
n Typically 8.3 − 6.0 ms (7,200 – 10,000RPM) or ½ rotation takes 37.4MB/sec
4.15-3ms n Read inner tracks: 22MB/sec 8Kbytes 3.7%
n Transfer bytes n Seek time and rotational
n Average transfer bandwidth (15-37 Mbytes/sec) latency dominates the cost 256Kbytes 55%
n Performance of transfer 1 Kbytes of small reads
n Seek (5.3 ms) + half rotational delay (3ms) + transfer (0.04 ms) n A lot of disk transfer 1Mbytes 83%
bandwidth is wasted
n Total time is 8.34ms or 120 Kbytes/sec!
n Need algorithms to reduce
n What block size can get 90% of the disk transfer seek time 2Mbytes 90%
bandwidth?

FIFO (FCFS) order SSTF (Shortest Seek Time First)

n Method n Method
n First come first serve n Pick the one closest on disk
0 53 199 0 53 199
n Pros n Rotational delay is in calculation
n Fairness among requests n Pros
n In the order applications n Try to minimize seek time
expect n Cons
n Cons n Starvation
n Arrival may be on random n Question
spots on the disk (long seeks)
n Is SSTF optimal?
n Wild swing can happen
n Can we avoid the starvation?

98, 183, 37, 122, 14, 124, 65, 67

98, 183, 37, 122, 14, 124, 65, 67
(65, 67, 37, 14, 98, 122, 124, 183)

4
 Elevator (SCAN) C-SCAN (Circular SCAN)
n Method n Method
n Take the closest request in the n Like SCAN
0 53 199 0 53 199
direction of travel n But, wrap around
n Real implementations do not go n Real implementation doesn’t go
to the end (called LOOK) to the end (C-LOOK)
n Pros n Pros
n Bounded time for each request n Uniform service time
n Cons n Cons
n Request at the other end will n Do nothing on the return
take a while

98, 183, 37, 122, 14, 124, 65, 67 98, 183, 37, 122, 14, 124, 65, 67
(37, 14, 65, 67, 98, 122, 124, 183) (65, 67, 98, 122, 124, 183, 14, 37)

Disk caching Disk Technology Trends

n Method
n Disk controller has a piece of RAM to cache recently accessed n Disks are getting smaller for similar capacity
blocks n Spin faster, less rotational delay, higher bandwidth
n Seagate ATA disk has .5MB and IBM Ultra160 SCSI has 16MB n Less distance for head to travel (faster seeks)
n Some of the RAM space stores “firmware” (an OS) n Lighter weight (for portables)
n Blocks are replaced usually in LRU order n Disk data is getting denser
n Pros n More bits/square inch
n Good for reads if you have locality n Tracks are closer together
n Cons n Doubles density every 18 months
n Expensive n Head close to surface
n Need to deal with reliable writes n Disks are getting cheaper ($/MB)
n About a factor of 2 per year since 1991