1 / 38

CPS110: Address translation

Learn about dynamic address translation and segmentation in virtual memory systems, including tradeoffs, algorithms, and pros/cons. Understand how segments can grow and be protected. Explore the complexities and solutions of managing virtual memory.

edwardsk
Download Presentation

CPS110: Address translation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPS110: Address translation Landon Cox February 19, 2008

  2. Dynamic address translation • Translator: just a data structure • Tradeoffs • Flexibility (sharing, growth, virtual memory) • Size of translation data • Speed of translation User process Translator (MMU) Physical memory Physical address Virtual address

  3. 1. Base and bounds • For each process • Single contiguous region of phys mem • Not allowed to access outside of region • Illusion own physical mem [0, bound)

  4. 1. Base and bounds Size of phys mem Base + Bound Bound Base 0 0 Virtual memory Physical memory

  5. 1. Base and bounds • Translator algorithm • Only kernel can change base, bound if (virtual address > bound) { trap to kernel kernel can kill process with segmentation fault } else { physical address = virtual address + base }

  6. 2. Segmentation • Segment • Region of contiguous memory • (both virtually and physically) • Idea • Generalize base and bounds • Create a table of base and bound pairs

  7. 2. Segmentation • Virtual address has two parts • Segment # (could be in high-order bits) • Offset (e.g. low-order bits of address) Code Data segment Stack segment Virtual info Physical info Same for both

  8. Virtual addresses VA={b31,b30,…,b12,b11,…,b1,b0} High-order bits (segment number) Low-order bits (offset)

  9. 2. Segmentation Code Data segment Stack segment Virtual memory (3,fff) . (Stack) (3,000) … (1,4ff) . (Data) (1,000) … (0,6ff) . (Code) (0,0) Physical memory 46ff . (Code segment) 4000 … 2fff . (Stack segment) 2000 … 4ff . (Data segment) 0 Offset Segment #

  10. 2. Segmentation • Not all virtual addresses are valid • Nothing in segment 2 • Nothing in segment 1 above 4ff • Valid = part of process’s address space • Accesses to invalid addresses are illegal • Hence a “segmentation fault” Code Data segment Stack segment Virtual memory (3,fff) . (Stack) (3,000) … (1,4ff) . (Data) (1,000) … (0,6ff) . (Code) (0,0)

  11. 2. Segmentation • Segments can grow • (can move to new physical location) • Protection • Different protections for segments • E.g. read-only or read-write • B&B forced uniform protection Code Data segment Stack segment Virtual memory (3,fff) . (Stack) (3,000) … (1,4ff) . (Data) (1,000) … (0,6ff) . (Code) (0,0)

  12. 2. Segmentation • What changes on a context switch? • Contents of segment table • Typically small (not many segments) Code Data segment Stack segment Virtual memory (3,fff) . (Stack) (3,000) … (1,4ff) . (Data) (1,000) … (0,6ff) . (Code) (0,0)

  13. Segmentation pros and cons • Pros • Multiple areas of address space can grow separately • Easy to share parts of address space • (can share code segment)

  14. Segmentation sharing Code Data segment Stack segment Code Data segment Stack segment Virtual info Physical info

  15. Segmentation pros and cons • Pros • Multiple areas of address space can grow separately • Easy to share parts of address space • (can share code segment) • Cons • Complex memory allocation • (still have external fragmentation)

  16. 2. Segmentation • Do we get virtual memory? • (can an address space be larger than phys mem?) • Segments must be smaller than physical memory • Address space can contain multiple segments • Can swap segments in and out • What makes this tricky? • Performance (segments are relatively large) • Complexity (odd segment sizes  packing problem) • Solution: fixed-size segments called pages!

  17. Course administration • Wednesday discussion section • Moved to D344 (same time) • Project 1 drawing to a close • Median score: 67% (not so hot) • Last semester at this time median was 98% • One group with 100% (another is close) • Some final tips …

  18. Course administration • What to carefully reread • Section 4.4 of the spec (ordering stuff) • Thread implementation slides • Lock implementation slides • I see a lot of code that ignore these sources • Other hints …

  19. Course administration /* * Allocate space for thread control block and * new stack. */ try { thread_ptr = new thread_t; thread_ptr->stack = NULL; thread_ptr->stack = new char [stack_size]; } catch(bad_alloc) { if (thread_ptr != NULL) { if (thread_ptr->stack != NULL) { delete [] thread_ptr->stack; } delete thread_ptr; } return(-1); }

  20. Course administration • Project 2 (virtual memory) out next Thursday • In some ways easier than P1 • In some ways harder than P1 (not given a solution) • Next deadline: midterm exam (February 26th) • In-class • One sheet (two sides) of notes • No laptops or other electronic resources • Practice exam in discussion section this week

  21. Midterm exam • What will be covered? • All threads/concurrency material • Project 1 • Lectures • Homework problems

  22. Analysis vs synthesis • No regurgitation questions • Analysis questions • Analyze system/program/design • Trace through program • Compute performance • Determine properties (deadlock, starvation, races) • Synthesis • Design/construct a new system/program/design • I like these more (e.g. learn the most doing projects)

  23. How to study • Do homework problems • Understand Project 1 • In groups • Create and answer questions I might ask • (you might get lucky; happened in past)

  24. Syntax for programs • Real or pseudo is fine (just be clear) • STL is fine • queue.{push, pop, front, empty} • Monitors • Project 1 syntax or OO syntax • thread_lock (lock_num) or mutex.lock () • Semaphores • OO syntax • sem1.up (), sem1.down (), sem2.up (), … • There is no “getVal” call! • Remember to specify initial value!!

  25. Syntax for traces • Thread: line number (or range of lines) 1: checkMilk () { 2: if (noNote) { 3: leave note 4: if (noMilk){ 5: buy milk; 6: } 7: remove note; 8: } 9: } Landon: 1-2 Melissa: 1-2 Landon: 3-6 Melissa: 3-6

  26. On-board review

  27. 3. Paging • Very similar to segmentation • Allocate memory in fixed-size chunks • Chunks are called pages • Why fixed-size pages? • Allocation is greatly simplified • Just keep a list of free physical pages • Any physical page can store any virtual page

  28. 3. Paging • Virtual addresses • Virtual page # (e.g. upper 20 bits) • Offset within the page (e.g. low 12 bits) • Each address refers to a byte of data • For 12-bit offset, how big are pages? • 4KB (2^12 different offsets)

  29. 3. Paging Why no bound column? • Translation data is a page table 2^20 – 1 Why?

  30. 3. Paging • Translation data is a page table How does page table’s size compare to segment table’s? Page table must reside in memory. Too large for registers alone.

  31. 3. Paging • Translation process if (virtual page # is invalid) { trap to kernel } else { physical page = pagetable[virtual page].physPageNum physical address is {physical page}{offset} }

  32. 3. Paging • What happens on a context switch? • Copy out contents of entire page table • Copy new page table into translation box • (hideously slow) • Instead, use indirection • Change page table base pointer (register) • Should point to new page table • Does this look like anything else we’ve seen? • Stack pointer

  33. 3. Paging • Pages can be in memory or swapped to disk • “Swapped out” = “paged out” • How can the processor know? • Is it in physical memory or paged out to disk? • Page table entry must have more info • Resident bit

  34. 3. Paging • Resident bit in page table entry • If bit is 1 (vp is in physical memory) • Page table entry has valid translation • Use to look up physical page • If bit is 0 (vp is swapped out) • MMU causes a page fault to OS • (runs kernel’s page fault handler) • (just like how timer interrupts are handled)

  35. 3. Paging • On a page fault, what does the OS do? • OS finds free physical page • (may have to page out another virtual page) • OS does I/O to read virtual page into mem • (or zero fills it, if it’s a new page) • What happens next? • OS reruns process’s at last faulting instruction • How does it know the last instruction? • Hardware provides process’s PC to handler on fault

  36. Valid vs. resident pages • Resident = page is in memory • Accessing non-resident pages is not an error • Access triggers page fault, OS handles it • Valid = page is legal to address • Who makes a virtual page resident (or not)? • OS memory manager (allocating physical memory)

  37. Valid vs. resident pages • Resident = page is in memory • Accessing non-resident pages is not an error • Access triggers page fault, OS handles it • Valid = page is legal to address • Who makes a virtual page valid (or not)? • User process controls this (with limits from OS)

  38. Valid vs. resident pages • Resident = page is in memory • Accessing non-resident pages is not an error • Access triggers page fault, OS handles it • Valid = page is legal to address • Why would a process make a page invalid? • Make the process fail-stop • Accidental/buggy references kill the process • Same for process making pages read-only • (writes to code segment are probably bugs)

More Related