Monday, November 1, 1993

Announcement:  Midterms returned in class today

Today: Allocation of Frames; Thrashing and working sets (chapter 8)
-------------------------------------------------------------------------------
Allocation of frames
M = size of physical memory
For process Pi,
	Di = number of frames allocated to Pi
	Si = size of the virtual memory of Pi
- minimum number of frames:
	Di >= maximum number of frames involved in an instruction
  (must have at least enough frames to hold all the different pages that any
  single instruction can reference)
- worst case scenario is architectures permitting multiple levels of
  indirection (e.g., indirect reference is to another page).  Presumably have a
  limit on the number of permissible levels of indirection to keep this in
  check
- maximum number of frames limited by size of memory
	Di <= min(M, Si)
---
Static allocation algorithms:
- equal share
	Di = M/n
  for n processes
- proportional algorithm (different processes need different amounts of memory)
	Di = M * Si/S
  where      -
	S  = \  Si
             /
             -
  so this allocates in proportion to the process' virtual memory
- previous restriction that Di >= #frames in an instruction
  still holds
-------------------------------------------------------------------------------
How do we determine n, the multiprogramming level?  Assume that all processes
are competing for a global pool of pages (*global page-replacement algorithm*).
Assume further that long term scheduler attempts to get maximum CPU utilization
with the following algorithm:
- monitor CPU utilization
- if CPU utilization is too low, increase n (to put more processes into the
ready queue)
- if CPU utilization is too high (ready queue getting too long), decrease n
Assumption: increasing n will result in increasing CPU utilization.
Actual effect is that CPU utilization increases with increasing n to some point
then rapidly drops toward 0.  Why?
*thrashing*
- examine single process as memory fills up
- process starts faulting and taking pages away from other processes.  Those
processes in turn must fault to bring their pages back.  Processes queue up for
the paging device and ready queue empties.  Scheduler sees decreasing CPU
utilization and increases the degree of multiprogramming.  CPU utilization
continues to drop
- effective access time increases and no useful work is getting done because
processes are spending all their time paging.
---
Thrashing
- a process is thrashing if it is spending more time paging than executing
- A system is thrashing if increasing the degree of multiprogramming reduces
CPU utilization
---
*Limit* (not prevent) effects of thrashing by using a *local* (or *priority*)
replacement algorithm.  Local replacement: each process must select a new frame
from only its own set of allocated frames (cannot take frames away from another
process).  [but system throughput is better with global replacement because a
process gives up unneeded pages.]
- in this case thrashing process cannot cause other processes to thrash (can't
steal pages from them).  Effective access time does increase however because of
greater contention for paging device caused by increased activity by thrashing
process.
---
To *prevent* thrashing, must come up with scheme to
- allocate sufficient frames to each process in memory (how do you determine
this?).
- increase degree of multiprogramming only if the current processes have had
enough frames and CPU utilization is still low.
---
Determining the "right" number of frames to allocate a process based on
"locality model" of process execution.
- Locality model: as proces executes it moves from (potentially overlapping)
  locality to locality.  Locality is a set of pages actively used together.
- if we do not allocate enough pages for process to accomodate current
  locality,  the process will thrash because it can't keep all the pages it
  needs in memory
---
Working-set model (P. Denning)
- assumption: process' memory access has property of locality
- working set of process: the most recent delta page references
- working set approximates process' locality
- can reuse pages outside of the working set
---
consider delta=5
Page reference trace 2 5 6 1 5 7 7 7 7 7 5 1 6 2 3 4 1 2 3 4 1 2 4
                              ^A          ^B          ^C
Working set at point A = {1, 2, 5, 6}
                     B = {5, 7}
                     C = {1, 2, 3, 4, 6}
Selection of delta tied to accuracy of working set.  Delta too small---doesn't
encompass working set, too large---overlaps several localities, delta
infinite---whole program
---
Size of working set of process i, WSSi, its most important property
Total demand for frames, D = sum (for all i) WSSi
if D > number of available frames, then thrashing will occur (some processes
need frames)
---
Difficulty in implementation is keeping track of working set window---every
page reference adds element to beginning of window, drops one from end.
- Approximate working set model with aging.
- For example, given reference bits, two in memory bits, delta of 10000 and
timer interrupt every 5000 references, shift in and clear reference bit on
every timer interrupt.  When page fault occurs, we can examine two copy bits
and reference bit to determine if page referenced in previous 10000 to 15000
instructions (why the range?)  Consider those pages with at least one of the
bits on to be in the working set.
-------------------------------------------------------------------------------
Final comment---note that higher level language programs may unintentionally
cause major amounts of paging---row major versus column major access in 2d
arrays, for example.
-------------------------------------------------------------------------------
Next: Chapter 9 (secondary storage management)