Add first part of chapter 8

Chapter8.md

+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)
+