1. 1 Virtual Memory zVM allows a program to run on a machine with less memory than it “needs”. zMany programs don’t need all of their code and data all at once (or ever), so this saves space and might permit more programs to shared primary memory (increase concurrency!) zThe amount of real memory that a program needs to execute can be adjusted dynamically to suit the programs behavior. zRelocation of programs. zSharing of protected memory space. zVM requires hardware support, plus OS management algorithms.

2. 2 The Memory Hierarchy

3. 3 Issues zMechanism yunderstanding how to make something “not there” appear there. zFetch strategies yWHEN to bring something into primary memory xdemand xanticipatory zReplacement strategies yWHICH page to throw out when you fetch something

4. 4 History zUniprogramming with overlays ymanual yno protection zMultiprogramming ymore than 1 job in memory at a time yfixed partition xresulted in internal fragmentation yvariable partition xexternal fragmentation yprotection xbase (and) bounds registers

5. 5 Early Memory management used Fixed Partitions P3P9P1P2 Internal fragmentation within each allocated segment. P1.Base Easy but limited. Add a processes virtual address to it’s base register. The size of each segment is fixed.

6. 6 Variable partition was a step forward zEach VA added to P.Base. zChecked against P.Bounds. zIf less then, access allowed to derived physical address. P1 EMPTY P2 P3 P.Base P.Bounds Could have external fragmentation.

7. 7 Virtual Memory zSeparate generated address from referenced address yP = F(V) xwhere P is a physical address; V is a virtual address xF is an arbitrary function. zMotivation yhave > 1 process in memory at a time yAllow sizeof(V) to be >> sizeof(P) xF is many to one. yAllow sizeof(P) to be >> sizeof(V) xF is one to many ySharing xF is many to many yProtection

8. 8 Dynamic Relocation Registers zAssociate with each process a base and bounds register yAdd base to virtual address yIf result is > bounds, fault. zReload relocation register on context switch. LD R3, @120# load R3 with contents of memory location 120 base = 10000 + > VA=120 bounds=11000 FAULT 10120 memory

9. 9 Segmentation zHave more than one (base, bounds) register pair per process ycall each a “segment” zSplit process into multiple segments ya segment is a collection of logically related data xcould be code, module, stack, file, etc zPut the segment registers into a table associated with each process. zInclude in the virtual address the segment number through which you are referencing memory. zBonus: add protection bits per segment into the table yNo Access, Read, Write, Execute

10. 10 Segment Table SEG # Offset Virtual Address 15 12 11 0 Segment table BASE BOUNDS ACCESS + ok? Physical memory How big can a segment be?

11. 11 The Segment Table zCan have one segment table per process zTo share memory, just share by putting the same translation into the base and bounds pair. zCan share with different protections. zCross-segment names can be tough to deal with ySegments need to have the same names in multiple processes if you want to share pointers. zIf the segment table is big, should keep it in main memory ybut then access is slow. zSo, keep a subset of the segments in a small on-chip memory and look up translation there. ycan be either automatic or manual.

12. 12 Paging solves the external fragmentation problem by using fixed sized units in both physical and virtual memory. virtual address space virt page 0 virt page 1 virt page 2 virt page 3 virt page 4 virt page 5 page 0 page 1 page 2 page 3 page 4 page 5 physical address space Paging

13. 13 Paging zGoals ymake allocation and swapping easier zMake all chunks of memory the same size ycall each chunk a “PAGE” yexample page sizes are 512 bytes, 1K, 4K, 8K, etc ypages have been getting bigger with time Page #Offset Virtual Address Page Table Base Register ++ => physical address Page Table Each entry in the page table is a “Page Table Entry”

14. 14 Paging zUser view memory as one contiguous address space from 0 through n. zIn reality, pages are scattered throughout physical storage. zThe mapping is invisible to the program; it is maintained by the OS and used by the hardware on each reference by the program. zProtection is provided because a program cannot reference memory outside of its VAS. zHardware always contains a TLB to speedup the page table lookups.

15. 15 Sharing zPaging introduces the possibility of sharing memory. zSeveral processes can share one or more pages, possibly with different protection. zA shared page may exist in different parts of the VAS of each process.

16. 16 An Example zPages are 1024 bytes long ythis says that bottom 10 bits of the VA is the offset zPTBR contains 2000 ythis says that the first page table entry for this process is at physical memory location 2000 zVirtual address is 2256 ythis says “page 2, offset 256” zPhysical memory location 2004 contains 8192 ythis says that each PTE is 4 bytes (1 word) yand that the second page of this process’s address space can be found at memory location 8192. zSo, we add 256 to 8192 and we get the real data!

17. 17 What does a PTE contain? M-bitV-bitProtection bitsPage Frame Number zThe Modify bit says whether or not the page has been written. yit is updated each time a WRITE to the page occurs. zThe Reference bit says whether or not the page has been touched yit is updated each time a READ or a WRITE occurs zThe V bit says whether or not the PTE can be used yit is checked each time the virtual address is used zThe Protection bits say what operations are allowed on this page yREAD, WRITE, EXECUTE zThe Page Frame Number says where in memory is the page R-bit 1 1 1 1-2about 20

18. 18 Segmentation and Paging at the Same Time zProvide for two levels of mapping zUse segments to contain logically related things ycode, data, stack ycan vary in size but are generally large. zUse pages to describe components of the segments ymakes segments easy to manage and can swap memory between segments. yneed to allocate page table entries only for those pieces of the segments that have themselves been allocated. zSegments that are shared can be represented with shared page tables for the segments themselves. yexamples include the VAX and the MIPS

19. 19 An Early Example -- IBM System 370 24 bit virtual address 4 bits8 bits12 bits Segment Table Page Table + simple bit operation Real Memory

20. 20 MIPS R3000 VM Architecture zUser mode and kernel mode y2GB of user space yWhen in user mode, can only access KUSEG. zThree kernel regions; all are globally shared. yKSEG0 contains kernel code and data, but is unmapped. Translations are direct. yKSEG1 like KSEG0, but uncached. Used for I/O space. yKSEG2 is kernel space, but cached and mapped. Contains page tables for KUSEG. xImplication is that the page tables are kept in VIRTUAL memory! Physical memory ffffffff 00000000 1ffffffff 512 MB 3684 MB 00000000 User Mapped Cacheable 7ffffffff KUSEG Kernel Unmapped Cached 9ffffffff KSEG0 Kernel Unmapped UnCached bffffffff KSEG1 Kernel mapped UnCached fffffffff KSEG2 Virtual memory

21. 21 Lookups zEach memory reference can be long yassuming no fault zCan exploit locality to improve lookup strategy ya process is likely to use only a few pages at a time zUse Translation Lookaside buffer to exploit locality ya TLB is a fast associative memory that keeps track of recent translations. zThe hardware searches the TLB on a memory reference zOn a TLB miss, either a hardware or software exception can occur yolder machines reloaded the TLB in hardware ynewer RISC machines tend to use software loaded TLBs xcan have any structure you want for the page table xfast handler computes.

22. 22 A TLB zA small fully associative cache zEach entry contains a tag and a value. ytags are virtual page numbers yvalues are physical page table entries. zProblems include ykeeping the TLB consistent with the PTE in main memory yWhat to do on a context switch ykeeping TLBs consistent on an MP. yquickly loading the TLB on a miss. zHit rates are important. Tag Value 0xfff1000 0xa10100 0xbbbb00 0x1111aa11 ? 0x12341111

23. 23 Selecting a page size zSmall pages give you lots of flexibility but at a high cost. zBig pages are easy to manage, but not very flexible. zIssues include yTLB coverage xproduct of page size and # entries yinternal fragmentation xlikely to use less of a big page y# page faults and prefetch effect xsmall pages will force you to fault often ymatch to I/O bandwidth xwant one miss to bring in a lot of data since it will take a long time.