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!

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

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

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 30-12 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

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

Hierarchical Page Table – Possible Structure

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.

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

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

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.

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.

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?