1. Some VM Complications Extra memory accesses Page tables are huge
One for translation
One for access
Page tables are huge
220 ~= 1 million entries
Page thrashing
Poor data usage patterns can destroy performance
Issues with caching
Do caches use virtual or physical addresses?
ABSTRACTION
VM can be compared to the development of high-level languages – the masking of details (in this case – hardware specifics) to increase the simplicity of writing code.
(also compares to OOP abstraction)
Also, related to Caching – memory as a cache for the disk!

2. Translation Lookaside Buffer
We fix the performance problem by avoiding the memory access in the translation from virtual to physical pages.
We buffer the common translations in a Translation lookaside buffer (TLB)
Basically, a specialized cache of the page table
Hit in the TLB – can skip the access to the page table
Miss in the TLB – have to do both accesses

3. TLB – a Cache for VM
Virtual page
Pg offset v
tag
Physical page

4. Size of page table How big is a page table entry?
For MIPS the virtual address is 32 bits
If the machine can support 1GB of physical memory and we use 4KB pages, then the physical page number is or 18 bits. Plus another valid bit + other useful stuff (read only, dirty, etc.)
Let say about 3 bytes.
How many entries in the page table?
MIPS virtual address is 32 bits – 12 bit page offset = 220 or ~1,000,000 entries
Total size of page table: ~ 3 megabytes

5. How can you organize the page table?
Continuous 3MB region of physical memory
Bounded size continuous region of physical mem
You will actually need 2 non-contiguous regions
Use a hash function instead of an array (“inverted page table”)
Slower, but less memory
Build a hierarchical page table
Super page table in physical memory
Second (and maybe third) level page tables in virtual address space
This allows you to page the page table
Virtual Superpage
Virtual page
Page offset

6. Hierarchical Page Table – Possible Structure

7. VM + Caching Access cache with virtual address?
fast, but every time we switch processes, we have to completely wipe the cache clean! (includes writing back all dirty blocks!)
Access cache with physical address?
slow, but fixes the aliasing problem in the cache
Virtually indexed, physically tagged
Index into the cache using the virtual index
This gets a set of tags
Compare the Physical page number with the tags to check for a cache hit.

8. Virtual Index/ Physical Tag
Virtual address
Virtual page
Page offset
Block
offset
index
tag
PPN
tag
PPN
Cache
Tag
cmp
TLB
tag
PPN
Set0 tag
tag
PPN
Set0 tag
PPN
Page offset
Set1 tag
Set1 tag
Tag
cmp
tag
Set2 tag
Set2 tag

9. What about writes?
Since Virtual Memory is just like a “cache” for the disk, we have to make a decision on how to handle writes (stores)
Due to the extremely long delay to disk, virtual memory systems use:
Write-Back ( AKA “Copy-Back” )
Each Page has a “dirty bit” which indicates that it has been written to
When a page is evicted from memory, it is written back to the disk or not based on that bit

10. How do we find it on disk? That is not a hardware problem! 
Most operating system partition the disk into logical devices (C: , D: , /home, etc.)
They also sometimes have a separate area to support the disk portion of virtual memory
Swap partition on UNIX machines
You then index into the correct page in the swap partition.

11. OS support for Virtual memory
It must be able to modify the page table register, update page table values, etc.
To enable the OS to do this, AND not the user program, we have different execution modes for a process – one which has executive (or supervisor or kernel level) permissions and one that has user level permissions.

12. Example Question
Consider a virtual memory system with the following parameters:
32-bit virtual address space (byte-addressed)
4 KB page size
28-bit physical address space (byte-addressed)
What is the:
number of bits needed to specify the virtual page number?
number of bits needed to specify the physical page number?