Add first part of chapter 8

Virtual Memory

==============

**Virtual Memory** loads the program's code and data on demand

- Upon reads, load memory from disk

- When memory is unused, write it to disk

Enablers

- Addresses are logical, not physical

- Runtime address translate (*paging and segmentation*) enable noncontiguous memory

    layouts.

**Implication: A process can successfully run without being fully resident in memory.**

Necessary things:

- next instruction to execute

- next data to be accessed

### How to do it:

1. load some part of the program

2. start executing, til program tries to read or execute something not in RAM

    (page fault).

3. Upon page fault, block the process, read in data, resume the process.

**Resident Set**: portion of process that is in main memory.

### Page Faults

How does the OS know when to load data?: CPU triggers a page fault upon access to

nonresident data/code.

Implications on performance: 

- Lazy loading is often a win; but

- disks load batches of data faster

Functionality win:

- Can juggle more process in memory at once

- A process can exceed system's RAM size

### Comparison

Real memory: backed by RAM chips

Virtual memory: RAM and swap space

Is virtual memory too slow?

Nope, key win of lazy loading: CPU keeps busy, hence less wasted time. Only a small

part of each process is active at a time (we hope)

**Principal of locality: Stufff you need in the future is close to stuff you needed

in the past**

### Requirements for Virtual memory

- Hardware must support paging and segmentation

- OS support for putting pages on disk and reloading them from disk

### Address Translation in a paging system

![Address Translation](res/address_translation.png)

Problem: page tables will still eat all the RAM! (e.g. 4MB of page tables per process

for 4GB RAM)

Solution: Paging page tables: put the page tables in virtual memory. Must keep 

page table entry of the currently-executing page in main memory.

![Two Level hierarchical page table](res/two_level_page_table.png)

![Address Translation in Two-level paging system](res/address_translation_two.png)

### Drawbacks of page table

- Page table size is proportional to the cirtual address space

Alternative: Inverted page table, by using a hash table:  

Inverted = index on frame#, not virtual address. Inverted tables grow with the 

size of physical memory.

![Inverted page table structure](res/inverted_page_table.png)

### Translation Lookaside Buffer

Each virtual memory reference can cause two physical memory accesses

- One to fetch the page table entry

- One to fetch the data

To get rid of the slowness, use **caches!**

![Use of a translation lookaside buffer](res/TLB.png)

![Operation of TLB](res/TLB_operation.png)

### Page Size

**Small**:

- Smaller page size, less amount of internal fragmentation (you can only allocate

    pages)

- Smaller page siez, more pages required per process

- More pages per process means larger page tables

- Larger page tablse means large portion of page tables in virtual memory

**Large**:

- Secondary memory is designed to efficiently transfer large blocks of data so a

    large page size is better (Disk produces streams)