Notes from Monday, May 5
Clint Mumaw

What was the point of today's lecture? 

--Paging allows for an arbitrary translation function (via table lookup) that 
gives greater flexibility for turning a virtual address into a physical 
address.



Paging hides the details of translation:  you get one giant segment of virtual 
address space, but it's virtualized to support an arbitrary translation 
function that's given by the page table.

The only details of paging that are exposed to the programmer are the page size 
(which is given by the size of the offset in the Virtual Address) and the 
number of pages in the Virtual Address Space (which is given by the number of 
bits in the Virtual Frame Number).

Once set, these details should be kept for many years to prevent programs from 
having to be rewritten.


Entry in a Page Table:
----------------------
A PTE is the result of a translation:  T(VA) -> PTE -> ___

PTE
-----------------------------------------
| R | W | X | r | m | v |      PFN      |
-----------------------------------------

v--valid bit:  whether the PFN can be used; whether there's a physical page 
that backs it.  Translation hardware checks and when the valid bit is off it 
triggers an exception/page fault.  The virtual frame number from the virtual 
address gets put into a register, the exception handler double-checks the page 
tables, sees that the valid bit is off then does one of several things.

1)  If it's the first reference to static data, an unused page gets assigned 
and initialized to 0, the valid bit is set, and the instruction causing the 
page fault gets re-executed.

2)  The page that was requested was moved to disk and the number in the PFN 
spot tells where to find the page on disk.  A disk request is issued and the 
process is put to sleep.  After the request is filled, the page number and the 
valid bit get set and the process is restarted.

3)  The page is already in memory in another process's address space (think 
fork) and the PFN just needs to point to the same place as the parent's.

4)  Something was referenced that doesn't exist, so the OS has to decide if it 
should exist.  The OS keeps track of the memory it has allocated to a 
program (in both the stack and the heap) and if a program tries to access 
memory beyond that, the OS kills the program.

Pages get populated from disk or with 0s, then it's up to the CPU and programs 
to manipulate values.


m--modified bit:  has the page been modified in memory since the last time 
the page was loaded?  This bit is used to tell the OS whether it can reconstruct the 
contents of the physical page by the same means as last time, or whether the 
contents must be stored to disk.  The hardware is responsible for setting this 
bit.


r--reference bit:  has the page been referenced since the last time this bit
was set to 0?  At any given time, most of your address space is not in use;
this bit is set by the hardware when a page is referenced.


protection (don't actually need 3 bits)
R:  programmer can read
W:  are allowed to write (can't execute or read)
X:  allowed to execute (is code)

The protections keep you from doing crazy things like writing to text segments.  
A page fault occurs when the protection required by an instruction exceeds the 
protection of a page.


An example with protections and laziness:

fork is supposed to yield a copy of the parent's address space.  On a fork, the 
valid bit is set off, then on a page fault the bit is flipped and the 
protection bits are set to deny write access to both parent and child (their 
PTEs are pointing to the same page).  When one of them wants to write, then a 
copy is made; "virtual" copying is used until real work is demanded.