CS 5460: Operating Systems
CS5460: Operating Systems Lecture 13: Memory Management (Chapter 8) - - PowerPoint PPT Presentation
CS5460: Operating Systems Lecture 13: Memory Management (Chapter 8) - - PowerPoint PPT Presentation
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
Where are we?
Basic OS structure, HW/SW interface, interrupts,
scheduling
Concurrency Memory management Storage management Other topics
CS 5460: Operating Systems
CS 5460: Operating Systems
Example Virtual Address Space
Typical address space has 4 parts – Code: binary image of program – Data: static variables (globals) – Heap : explicitly allocated data (malloc) – Stack: implicitly allocated data Kernel mapped into all processes MMU hardware: – Remaps virtual addresses to physical – Supports read-only, supervisor-only – Detects accesses to unmapped regions How can we load two processes
into memory at same time?
– Assume each has similar layout
Kernel code segment Kernel data segment
Kernel heap
User code segment User data segment User heap User stack segment
Kernel User
0x00000000 0x80000000 0xFFFFFFFF
PC HP SP
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)
One process at a time User code compiled to sit in
fixed range (e.g., [0,640 KB])
– No hardware virtualization of addresses
OS in separate addresses
– E.g., above 640KB
Goals:
– Safety: None (good and bad) – Efficiency: Poor (I/O and compute not overlapped, response time)
Code (Text segment) Static data (Data segment) Uninitialized data (BSS segment)
0x00000000 0xFFFFFFFF
Heap (Dynamically allocated) Stack
SP HP PC 0xA0000
Reserved for DOS kernel
CS 5460: Operating Systems
Multiprogramming: Static Relocation
OS loader relocates programs – OS stored in reserved “high” region – Compiler maps process starting at 0 – When process started, OS loader:
» Allocates contiguous physical memory » Uses relocation info in binary to fix up addresses to relocated region
– TSRs in DOS based on this technique Problems: – Finding/creating contiguous holes – Dealing with processes that grow/shrink Goals: – Safety: None! à à process can destroy
- ther processes
– Efficiency: Poor à à only one segment per process; slow load times; no sharing
Code Data
0x00000000 0xFFFFFFFF
Heap Stack
SP1 HP0 PC0
Reserved for OS kernel Code Data Heap Stack
SP0 HP1 PC1
CS 5460: Operating Systems
Dynamic Relocation
Idea:
– Programs all laid out the same – Relocate addresses when used – “Requires” hardware support
Two views of memory:
– Virtual: Process’s view – Physical: Machine’s view
Many variants
– Base and bounds – Segmentation – Paging – Segmented paging
0x00000000 0xFFFFFFFF
SP1
OS kernel
Code Data Heap Stack
OS kernel
Code Data Heap Stack
OS kernel
Heap Data Code Stack Stack Heap Data Code
0x00000000 0xFFFFFFFF
SP0 HP0 PC0 HP1 PC1
Physical Addresses Virtual Addresses
CS 5460: Operating Systems
Base and Bounds
Each process mapped to
contiguous physical region
Two hardware registers
– Base: Starting physical address – Bounds: Size in bytes
On each reference:
– Check against bounds – Add base to get physical address
Evaluation:
– Good points: … – Bad points: …
OS handled specially Example: Cray-1
Base register Bounds register Virtual address
>?
Physical address Trap
+
0x00000000 0xFFFFFFFF
Code Data Heap Stack OS kernel Code Data Heap Stack Base0 Bounds1 Base1 Bounds0
0x00000 0x00000 0x00000 0x7ffff 0x7ffff
P1 VAs P0 VAs Physical Virtual
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 Base Bounds Base Bounds Base Bounds Base Bounds Base Bounds
…
>?
Error! (Trap)
+
Physical address
CS 5460: Operating Systems
Segmentation Example
Virtual address space is 2000
bytes in size
4 segments up to 500 bytes
each
– Starting at 0, 500, 1000, 1500
What if processor accesses…
– VA 0 – VA 1040 – VA 1900 – VA 920 – VA 1898
What if we allocate:
– 100-byte segment – 200-byte segment
Base Bounds 1000 400 500 600 300 1500 400
- 1
- 2
- 3
Seg3 Seg0 Seg2 Seg1 2000 1000 Seg3 Seg0 Seg2 Seg1 Virtual Address Physical Address Segment Table
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
Physical Page# Other Physical address Virtual Page# Offset Physical Page# Other Physical Page# Other Physical Page# Other Physical Page# Offset Wired concatenate What other info?
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
Assume 1000-byte pages What if processor accesses:
– VA 0 – VA 1040 – VA 2900 – VA 920 – VA 4998
- 1
- 2
- 3
VP3 VP0 VP2 VP1 Virtual Address Physical Address PPN Valid R/O Super 3 Y N Y 8 N N N 5 Y Y N 7 Y N N 1 N Y Y
- 4
VP4 VP0 VP1 VP2 VP3 VP4 Free List Page Table
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