Monday, October 25, 1993

Announcement: (previously announced via email)
	Course notes now ftp-able on ftp.cs.tamu.edu in /pub/furuta/cpsc410
	You can also look at them with gopher
Today: Virtual Memory (Chapter 8)
-------------------------------------------------------------------------------
- Virtual memory: permit execution of processes that are not entirely in memory
(chapter 7's techniques have assumed all of process is in memory)
- Virtual memory can present programmer a view of memory as a large, uniform
array of storage.  |logical storage| >= |physical storage|
	- large permits programs to be be larger than physical space
	- uniform frees programmer from concerns over memory storage
	  limitations and characteristics
- Also takes into account following points:
	- in many cases, the entire program is not needed to be in memory (or
	  at least not in memory at the same time)
		- error code; sparse arrays; specialist commands
	- common estimate is that program spends 90% of time in 10% of code
	- Often the program's demand on memory changes during run time.
	- More efficient use of memory results if only have to keep active part
	  in physical memory.  More users can fit into memory; less i/o to
	  bring in only active part to memory (hence faster)
-------------------------------------------------------------------------------
Demand paging: only bring in pages that are needed
- similar to swapping but bringing in *parts* of process.  *pager* instead
  of swapper (swap is entire process)
- hardware support required.  valid/invalid bit attached to each page table
  entry.  When "valid" associated page is in memory.  "invalid" means it is
  not.  Page table has two fields then, frame number and valid/invalid bit.
- page fault: attempt to access address on "invalid" page
-------------------------------------------------------------------------------
On page fault
1. check the process' page table to see if the page is in memory (if it is then
   the cause of the fault is an invalid memory access so abort)
2. If not in memory, trap to the operating system

O.S. then does the following:
- suspend the process, saving user registers and process state
- locate a free frame (or create one)---to be discussed
- determine that the page reference was legal and determine the location of
  the page on disk (backing store)
- bring in the missing page to memory
	transfer requires the following
	- wait in queue for device until read request is serviced
	- wait for device seek and/or latency time
	- begin tranfer to free frame
- while waiting for the transfer to complete let another process use the CPU
- on interrupt from the disk save registers and process state for other user
- correct page tables by marking page "valid"
- reset process' PC in PCB so that when it starts the instruction will be
  re-executed
- change process state from "waiting" to "ready"
-------------------------------------------------------------------------------
Instructions with multiple addresses and/or registers
- if page fault occurs in middle of execution some of memory or registers may
have been changed [example MOVE (SP)+, R2]
- reexecuting the instruction may not be correct
So possible solutions
- determine if there is a page fault before any modification is done
- hold results until it is certain that there is no page fault.
Easiest to handle this kind of issue in machine design---waiting until after
the fact is more complicated because of need to workaround.  Indeed may not be
possible to detect all such side effects without hardware assistance
-------------------------------------------------------------------------------
Summary, overall tasks:
- service the page-fault interrupt (several hundred instructions)
- read in the page (significant amounts of time)
- restart the process (several hundred instructions)

Disk i/o to swap space is generally faster than to file system because blocks
larger, no file lookups but also may be of limited size.  Initially if size is
not a factor can bring entire executable image into swap space.  If more of a
factor, bring in page from file system to swap space on first reference and
then use swap space subsequently.

Effective access time (average time taken by a memory access) based on
- ma: average time for a memory access without a page fault.  about 100
  nanoseconds
- page fault time:
	- os service time when page fault detected (about 100 microseconds)
	- time to read page into memory (about 25 milliseconds)
	- time to restart process (about 100 microseconds)
- p: probability that a page fault occurs when a memory reference is made
e.a.t. =  (1-p)*ma + p*page-fault-time
So e.a.t. becomes unbearable if there are a lot of page faults

Key notion: to reduce the "effective access time" reduce the number of page
faults.  This will be critical issue.
-------------------------------------------------------------------------------
When to bring pages into memory (and into swap space) is a scheduling issue.
Demand paging is one approach.  Also may want, for example, to prepage or let
user specify what pages to bring in.

Another scheduling question is when to *replace* pages already in memory
- no frames on free frame list, how do we decide what to remove from memory?
- the replacement algorithm is key in reducing the effective access time.
- would think that allocating more pages to a process would also reduce e.a.t.
  but we'll see an anomalous result here
-------------------------------------------------------------------------------
Next time: page-replacement algorithms