1 / 167

e cs150 Spring 2014 : Operating System #4: Memory Management (chapter 5)

e cs150 Spring 2014 : Operating System #4: Memory Management (chapter 5). Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com. text. data. BSS. user stack. args/env. kernel.

reese
Download Presentation

e cs150 Spring 2014 : Operating System #4: Memory Management (chapter 5)

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. ecs150 Spring 2014:Operating System#4: Memory Management(chapter 5) Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com ecs150, Spring 2014

  2. ecs150, Spring 2014

  3. text data BSS user stack args/env kernel Modified (dirty) pages are pushed to backing store (swap) on eviction. file volume with executable programs data Fetches for clean text or data are typically fill-from-file. Paged-out pages are fetched from backing store when needed. Initial references to user stack and BSS are satisfied by zero-fill on demand. ecs150, Spring 2014

  4. Logical vs. Physical Address • The concept of a logical address space that is bound to a separate physicaladdress space is central to proper memory management. • Logical address – generated by the CPU; also referred to as virtual address. • Physical address – address seen by the memory unit. • Logical and physical addresses are the same in compile-time and load-time address-binding schemes; logical (virtual) and physical addresses differ in execution-time address-binding scheme. ecs150, Spring 2014

  5. Memory-Management Unit (MMU) CPU • Hardware device that maps virtual to physical address. • In MMU scheme, the value in the relocation register is added to every address generated by a user process at the time it is sent to memory. • The user program deals with logical addresses; it never sees the real physical addresses. Virtual address MMU Data Physical address Memory ecs150, Spring 2014

  6. Paging: Page and Frame • Logical address space of a process can be noncontiguous; process is allocated physical memory whenever the latter is available. • Divide physical memory into fixed-sized blocks called frames(size is power of 2, between 512 bytes and 8192 bytes). • Divide logical memory into blocks of same size called pages. • Keep track of all free frames. • To run a program of size n pages, need to find n free frames and load program. • Set up a page table to translate logical to physical addresses. • Internal fragmentation. ecs150, Spring 2014

  7. frames ecs150, Spring 2014

  8. Address Translation Architecture ecs150, Spring 2014

  9. Address Translation Scheme • Address generated by CPU is divided into: • Page number(p) – used as an index into a pagetable which contains base address of each page in physical memory. • Page offset(d) – combined with base address to define the physical memory address that is sent to the memory unit. ecs150, Spring 2014

  10. MAPPING in MMU Virtual Memory ecs150, Spring 2014

  11. shared by all user processes ecs150, Spring 2014

  12. kernel ecs150, Spring 2014

  13. ecs150, Spring 2014

  14. virtual memory (big) physical memory (small) backing storage executable file text data BSS header pageout/eviction text user stack data idata data args/env wdata kernel symbol table, etc. page fetch program sections physical page frames process segments MAPPING in MMU virtual-to-physical translations How to represent  ecs150, Spring 2014

  15. Paging • Advantages? • Disadvantages? ecs150, Spring 2014

  16. Fragmentation • External Fragmentation – total memory space exists to satisfy a request, but it is not contiguous. • Internal Fragmentation – allocated memory may be slightly larger than requested memory; this size difference is memory internal to a partition, but not being used. • Reduce external fragmentation by compaction • Shuffle memory contents to place all free memory together in one large block. • Compaction is possible only if relocation is dynamic, and is done at execution time. • I/O problem • Latch job in memory while it is involved in I/O. • Do I/O only into OS buffers. ecs150, Spring 2014

  17. Page size? Page Table Size? ecs150, Spring 2014

  18. 1 page = 212 220 pages 222 bytes 4 MB 32 bits Address bus 232 bytes 1 page = 4K bytes 256M bytes main memory ecs150, Spring 2014

  19. Page Table Entry referenced modified present/absent caching disabled protection page frame number 2^20 * 4 bytes = ? 2^22 bytes 4 MB 2^52 * 8 bytes = ? 2^55 bytes 32 PB ecs150, Spring 2014

  20. Free Frames Before allocation After allocation ecs150, Spring 2014

  21. Page Faults • Page table access • Load the missing page (replace one) • Re-access the page table access. • How large is the page table? • 232 address space, 4K (212) size page. • How many entries? 220 entries (1 MB). • If 246, you need to access to both segment table and page table…. (226 GB or 216 TB) • Cache the page table!! ecs150, Spring 2014

  22. Page Faults • Hardware Trap • /usr/src/sys/i386/i386/trap.c • VM page fault handler  vm_fault() • /usr/src/sys/vm/vm_fault.c ecs150, Spring 2014

  23. /usr/src/sys/vm/vm_map.h On the hard disk or Cache – Page Faults How to implement? ecs150, Spring 2014

  24. Implementation of Page Table • Page table is kept in main memory. • Page-tablebase register (PTBR) points to the page table. • Page-table length register (PRLR) indicates size of the page table. • In this scheme every data/instruction access requires two memory accesses. One for the page table and one for the data/instruction. • The two memory access problem can be solved by the use of a special fast-lookup hardware cache called associative memory or translation look-aside buffers(TLBs) ecs150, Spring 2014

  25. Two Issues • Virtual Address Access Overhead • The size of the page table ecs150, Spring 2014

  26. TLB (Translation Lookaside Buffer) • Associative Memory: • expensive, but fast -- parallel searching • TLB: select a small number of page table entries and store them in TLB virt-page modified protection page frame 140 1 RW 31 20 0 RX 38 130 1 RW 29 129 1 RW 62 ecs150, Spring 2014

  27. Associative Memory • Associative memory – parallel search Address translation (A´, A´´) • If A´ is in associative register, get frame # out. • Otherwise get frame # from page table in memory Page # Frame # ecs150, Spring 2014

  28. ecs150, Spring 2014

  29. Paging Hardware With TLB TLB Miss Versus Page Fault ecs150, Spring 2014

  30. Page Table ecs150, Spring 2014

  31. Brainstorming • How to design an “inverted page table” such that we can do it “faster”? ecs150, Spring 2014

  32. ecs150, Spring 2014

  33. Hardware or Software • TLB is part of MMU (hardware): • Automated page table entry (pte) update • OS handling TLB misses • Why software???? • Reduce HW complexity • Flexibility in Paging/TLB content management for different applications ecs150, Spring 2014

  34. Inverted Page Table • 264 address space with 4K pages • page table: 252 ~ 1 million gigabytes ecs150, Spring 2014

  35. Inverted Page Table (iPT) • 264 address space with 4K pages • page table: 252 ~ 1 million gigabytes • One entry per one page of real memory. • 128 MB with 4K pages ==> 214 entries • Disadvantage: • For every memory access, we need to search for the whole paging hash list. ecs150, Spring 2014

  36. Inverted Page Table 4GB 1KB 8 bytes (64 bits) sizeof(IPT)? ecs150, Spring 2014

  37. ecs150, Spring 2014

  38. Hashed Page Tables • Common in address spaces > 32 bits. • The virtual page number is hashed into a page table. This page table contains a chain of elements hashing to the same location. • Virtual page numbers are compared in this chain searching for a match. If a match is found, the corresponding physical frame is extracted. ecs150, Spring 2014

  39. Hash virtual page# virtual page# physical page# ecs150, Spring 2014

  40. ecs150, Spring 2014

  41. iPT/Hash Performance Issues • still do TLB (hw/sw) • if we can hit the TLB, we do NOT need to access the iPT and hash. • caching the iPT and/or Hash Table?? • any benefits under regular on-demand caching schemes? • hardware support for iPT/Hash ecs150, Spring 2014

  42. TLB (Translation Lookaside Buffer) • Associative Memory: • expensive, but fast -- parallel searching • TLB: select a small number of page table entries and store them in TLB virt-page modified protection page frame 140 1 RW 31 20 0 RX 38 130 1 RW 29 129 1 RW 62 ecs150, Spring 2014

  43. Paging Virtual Memory • CPU address-ability: 32 bits -- 232 bytes!! • 232 is 4 Giga bytes (un-segmented). • Pentium II can support up to 246 (64 Tera) bytes • 32 bits – address, 14 bits – segment#, 2 bits – protection. • Very large addressable space (64 bits), and relatively smaller physical memory available… • Let the programs/processes enjoy a much larger virtual space!! ecs150, Spring 2014

  44. MAPPING in MMU VM with 1 Segment ecs150, Spring 2014

  45. Eventually… ??? MAPPING in MMU ecs150, Spring 2014

  46. On-Demand Paging • On-demand paging: • we have to kick someone out…. But which one? • Triggered by page faults. • Loading in advance. (Predictive/Proactive) • try to avoid page fault at all. ecs150, Spring 2014

  47. Demand Paging • On a page fault the OS: • Save user registers and process state. • Determine that exception was page fault. • Find a free page frame. • Issue read from disk to free page frame. • Wait for seek and latency and transfers page into memory. • Restore process state and resume execution. ecs150, Spring 2014

  48. Page Replacement • Find the location of the desired page on disk. • Find a free frame: - If there is a free frame, use it. - If there is no free frame, use a page replacement algorithm to select a victim frame. • Read the desired page into the (newly) free frame. Update the page and frame tables. • Restart the process. ecs150, Spring 2014

  49. Page Replacement Algorithms • minimize page-fault rate ecs150, Spring 2014

  50. Page Replacement • Optimal • FIFO • Least Recently Used (LRU) • Not Recently Used (NRU) • Second Chance • Clock Paging ecs150, Spring 2014

More Related