CS5460: Operating Systems

CS5460: Operating Systems

CS5460: Operating Systems Lecture 13: Memory Management (Chapter 8) CS 5460: Operating Systems Where are we? Basic OS structure,• HW/SW interface, interrupts, scheduling • •Concurrency • Memory management Storage management Other topics CS 5460: Operating Systems Example Virtual Address Space 0xFFFFFFFF Typical address space has 4 parts User stack segment SP – Code: binary image of program – Data: static variables (globals) HP – Heap : explicitly allocated data (malloc) User heap – Stack: implicitly allocated data User Kernel mapped into all processes User data segment MMU hardware: PC User code segment – Remaps virtual addresses to physical 0x80000000 – Supports read-only, supervisor-only Kernel heap – Detects accesses to unmapped regions How can we load two processes Kernel data segment into memory at same time? – Assume each has similar layout Kernel Kernel code segment 0x00000000 CS 5460: Operating Systems Mapping Addresses How can process (virtual) addresses be mapped to physical addresses? – Compile time: Compiler generates physical addresses directly » Advantages: No MMU hardware, no runtime translation overhead » Disadvantages: Inflexible, hard to multiprogram, inefficient use of DRAM – Load time: OS loader “fixes” addresses when it loads program » Advantages: Can support static multiprogramming » Disadvantages: MMU hardware, inflexible, hard to share data, … – Dynamic: Compiler generates address, but OS/HW reinterpret » Advantages: Very flexible, can use memory efficiently » Disadvantages: MMU hardware req’d, runtime translation overhead For “real” OSes, processes only use virtual addresses – Small-sized embedded systems use physical addresses CS 5460: Operating Systems Uniprogramming (e.g., DOS) 0xFFFFFFFF One process at a time Reserved for User code compiled to sit in DOS kernel fixed range (e.g., [0,640 KB]) 0xA0000 Stack – No hardware virtualization of SP addresses OS in separate addresses HP – E.g., above 640KB Heap (Dynamically allocated) Goals: Uninitialized data (BSS segment) – Safety: None (good and bad) – Efficiency: Poor (I/O and compute Static data not overlapped, response time) (Data segment) PC Code (Text segment) 0x00000000 CS 5460: Operating Systems Multiprogramming: Static Relocation 0xFFFFFFFF OS loader relocates programs – OS stored in reserved “high” region Reserved for – Compiler maps process starting at 0 OS kernel – When process started, OS loader: » Allocates contiguous physical memory Stack » Uses relocation info in binary to fix up SP1 addresses to relocated region – TSRs in DOS based on this technique HP 1 Heap Problems: Data – Finding/creating contiguous holes PC1 – Dealing with processes that grow/shrink Code Goals: Stack SP0 – Safety: None! à process can destroy other processes HP0 – Efficiency: Poor à only one segment Heap per process; slow load times; no Data sharing PC0 Code 0x00000000 CS 5460: Operating Systems Dynamic Relocation Physical Addresses 0xFFFFFFFF Idea: Stack SP 0 Data – Programs all laid out the same HP0 – Relocate addresses when used Heap Data – “Requires” hardware support Data Code Heap Two views of memory: PC0 – Virtual: Process’s view OS kernel Code – Physical: Machine’s view 0x00000000 Stack Many variants 0xFFFFFFFF – Base and bounds Stack Heap SP1 – Segmentation HP 1 Stack – Paging Heap Virtual Data – Segmented paging Addresses Code PC1 Code OS kernel OS kernel 0x00000000 CS 5460: Operating Systems Base and Bounds Trap Each process mapped to contiguous physical region Virtual address Bounds register Two hardware registers >? – Base: Starting physical address – Bounds: Size in bytes + Base register Physical On each reference: address – Check against bounds Virtual Physical 0xFFFFFFFF – Add base to get physical address OS kernel 0x00000 0x7ffff Evaluation: Stack Bounds – Good points: … Heap 1 P1 VAs Data – Bad points: … Code 0x00000 Base1 OS handled specially 0x7ffff Stack Bounds Example: Cray-1 Heap 0 P0 VAs Data Base0 Code 0x00000 0x00000000 CS 5460: Operating Systems Base and Bounds Each process has private address space – No relocation done at load time Operating system handled specially – Runs with relocation turned off (i.e., ignores Base and Bounds) – Only OS can modify Base and Bounds registers Good points: – Very simple hardware Bad points: – Only one contiguous segment per process à inhibits sharing – External fragmentation à need to find or make holes – Hard to grow segments CS 5460: Operating Systems Segmentation Idea: Create N separate segments – Each segment has separate base and bounds register – Segment number is fixed portion of virtual address Seg# Offset >? Error! (Trap) Base Bounds Base Bounds Base Bounds + Physical … address Base Bounds Base Bounds CS 5460: Operating Systems Segmentation Example Virtual address space is 2000 Base Bounds bytes in size • 0 1000 400 Segment 4 segments up to 500 bytes • 1 0 500 each Table • 2 600 300 – Starting at 0, 500, 1000, 1500 • 3 1500 400 What if processor accesses… – VA 0 Virtual Address Physical Address 2000 – VA 1040 Seg3 Seg3 – VA 1900 – VA 920 Seg0 – VA 1898 Seg2 1000 What if we allocate: Seg1 Seg2 – 100-byte segment – 200-byte segment Seg1 Seg0 0 CS 5460: Operating Systems Segmentation Discussion Good features: – More flexible than base and bounds à enables sharing (How?) – Reduces severity of fragmentation (How?) – Small hardware table (e.g., 8 segments) à can fit all in processor Problems: – Still have fragmentation à How? What kind? – Hard to grow segments à Why? – Non-contiguous virtual address space à Real problem? Possible solutions: – Fragmentation: Copy and compact – Growing segments: Copy and compact – Paging CS 5460: Operating Systems Paging Problem w/ segmentation à variable-sized segments Solution à Paging! – Insist that all “chunks” be the same size (typically 512-8K bytes) – Call them “pages” rather than “segments” – Allocation is done in terms of full page-aligned pages à no bounds – MMU maps virtual page numbers to physical page numbers Virtual Page# Offset Wired concatenate Physical Page# Other Physical Physical Page# Offset Physical Page# Other address Physical Page# Other What other info? Physical Page# Other CS 5460: Operating Systems Paging Discussion How does this help? – No external fragmentation! – No forced holes in virtual address space – Easy translation à everything aligned on power-of-2 addresses – Easy for OS to manage/allocate free memory pool What problems are introduced? – What if you do not need entire page? Internal fragmentation – Page table may be large » Where should we put it? – How can we do fast translation if not stored in processor? – How big should you make your pages? » Large: Smaller table, demand paging more efficient » Small: Less fragmentation, finer grained sharing, larger page table CS 5460: Operating Systems Paging Examples Page Table PPN Valid R/O Super • 0 3 Y N Y • 1 8 N N N Assume 1000-byte pages • 2 5 Y Y N What if processor accesses: • 3 7 Y N N – VA 0 • 4 1 N Y Y – VA 1040 – VA 2900 Virtual Address Physical Address – VA 920 VP1 – VA 4998 VP3 VP2 VP4 VP3 VP0 VP2 VP1 VP4 Free VP0 List CS 5460: Operating Systems x86 Paging x86 typically uses 4 KB pages Virtual addresses are 32 bits How big is the offset field of a virtual address? How big is the virtual page number field? How many pages are in a virtual address space? How big is a flat page table? – Assume PTE (page table entry) is 32 bits CS 5460: Operating Systems Key Idea From Today Address space virtualization – Programs see virtual addresses – Kernel can see both virtual and physical addresses – Virtual and physical address spaces need not be the same size – You must understand this to understand modern operating systems Kernel + HW supports the virtual to physical mapping – Has to be fast – There are different ways to do it – Modern OSes use paging CS 5460: Operating Systems .

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    17 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us