8/25/2014cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington1 Memory...

04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 1

Memory Management

CSE 410, Spring 2008

Computer Systems

http://www.cs.washington.edu/410


Readings and References

• Reading » Chapter 9, Operating System Concepts, Silberschatz, Galvin, and

Gagne

• Other Readings

» P&H:

» P&H CDA-AQA:


Review: Program Memory Addresses

• Program addresses are fixed at the time the source file is compiled and linked

• Small, simple systems can use program addresses as the physical address in memory

• Modern systems usually much more complex» program address space very large» other programs running at the same time» operating system is in memory too


heapprogram

stackphysical

memory

programaddresses

physicaladdresses

Direct Physical Addressing


Physical Addresses

• Address generated by the program is the same as the address of the actual memory location

• Simple approach, but lots of problems» Only one process can easily be in memory at a time

» There is no way to protect the memory that the process isn't supposed to change (ie, the OS or other processes)

» A process can only use as much memory as is physically in the computer

» A process occupies all the memory in its address space, even if most of that space is never used• 2 GB for the program and 2 GB for the system kernel

Absolute Code


• Compile time: if it can be known in advance the starting address of a program in memory, then absolute code can be generated.

• .com-format programs (MSDOS)

• Output: a.exe, a.o, or an object module

• Q:In a multiprogrammed environment, can I run two of these synchronously?

• Q: Can I relocate this code (say, to coalesce memory gaps when dealing with fragmentation)


heapprogram

stack

physical

memory

heapprogram

stack

heapprogram

stack

programaddresses

physicaladdresses

memorymapping

disk

Memory Mapping

Address Binding


• Symbolic Addresses

• Relocatable Code Absolute Code

• Loader produces the final address binding(no dynamic relocation)

• Run-time environment produces the final address binding (with dynamic relocation)

Intro to Address Bindings


• Compiler/assembler

• Symbolic -> Absolute

• Symbolic -> Relocatable

• Loader

• Relocatable-> final binding

• Runtime environment

• Relocatable-> final binding

Address Generation and Binding


• Source code produces symbolic addresses• Array1, x, y, count• An abstraction offered to us by our assembler

• A compiler will bind these symbolic addresses to • Absolute addresses

• Symbolic address was x, absolute (physical address) is 0x04

• Relocatable addresses• Symbolic address was x, relocatable address is

“16 bytes from the beginning of this file”

Address Transformations


• Load Time

• Loader: ties in other libraries and…

• If we couldn’t deduce our starting address statically, our compiler would generate instead relocatable code

• “14 bytes from the beginning of this file”

• All address bindings would be delayed until loading, at which point a starting offset defines every address in the program (like absolute).

Final Address Binding


• Done at runtime• Rather than x, which is our second word in the data

section, we might call it “+4bytes from start”• If the starting address isn’t known in advance, then

the relocatable->logical binding is delayed…• Binding at run time, if to be dynamically

relocated during execution• This more complex binding scheme is the only

in which the logical address space and the physical address space differ!

Relocatable Code


• An O.S. today will dynamically relocate processes from one section of the memory space to another.

• Delay binding of the relocatable addresses till runtime

• Addresses up to this stage will be in some intermediary form, and then will be bound dynamically

• MS-DOS, x86: 4 relocation registers


Virtual Addresses• The program addresses are now considered to

be “virtual addresses”» Aka, logical addresses

• The memory management unit (MMU) translates the program addresses to the real physical addresses of locations in memory

• The user program never sees the real physical address – always a logical address» A program can create a pointer to 0x05 and store

to that location in memory, read from it, etc.

Logical Memory V.S. Physical Memory• The concept of a logical address space that is mapped

(bound) to a physical address space is central to good memory management.

• Really, this is just another abstraction in which we decouple our program’s internal addresses from the physical array (with physical addresses) that defines main memory.

• It’s the job of the MMU (memory mapping hardware) to sustain this illusion, providing a reliable function whose input is the program’s logical address and whose output is the corresponding physical address



Physical Memory Layout

• Contiguous Allocation» Each process gets a single range of addresses» Single-partition allocation

• one process resident at a time

» Multiple-partition allocation• multiple processes resident at a time

• Noncontiguous allocation» Paging, segmentation, or a combination


OS

Edit

unused

0x0000

0xFFFF

Uniprogramming without Protection

• Application always runs at the same place in physical memory

• Process can access all memory even OS» program bug crashes the

machine

• MS-DOS


Solitaire

OS

Word

unused

0x0000

0xFFFF

0x7000

Multiprogramming without Protection

• When a program is loaded the linker-loader translates a program's memory accesses (loads, stores, jumps) to where it will actually be running in memory» Still no protection

• Once was very common

• Windows 3.1, Mac OS 9


Multiprogramming with Protection

• Restrict what a program can do by restricting what it can touch

• User process is restricted to its own memory space» can't crash OS» can't crash other process

• How?» "All problems can be solved with another level of indirection"


Simple Translation: Base/Bounds

• Each process has a base register» added to every memory

reference

• Each process has a bounds register» no memory reference

allowed beyond here

Word

Solitaire

OS

base reg =0x200000

base reg =0x600000

bounds reg =0x500000



Base/Bounds

• Word references 0x004FF00 - valid

• Solitaire references 0x1100C0 - error

Virtual Address

+

>

Base register

Bounds register

Physical Address

ERROR!

yes

Word

Solitaire

OS

base reg =0x200000

base reg =0x600000




Fragmentation

OS

P1

P2

P3

OS

P1

P3

OS

P1

P3

P4

OS

P3

P4

OS

P3

P4

P5

OS

P1

OS

P1

P2

OS

OS

P3

P4

P5

P6

compaction

• Over time unused memory is spread out in small pieces» external fragmentation

• Rearrange memory to make room for the next program» compaction = lots of copying (expensive)» change base/bounds registers for moved programs


Base/bounds Evaluation

• Advantages of base/bounds» process can't crash OS or other processes

» can move programs around and change base register

» can change program memory allocation by changing bounds register

• Problems with base/bounds» external fragmentation

» can't easily share memory between processes

» programs are limited to amount of physical memory

» doesn’t improve support for sparse address spaces

Paging

• Divide a process's virtual address space into fixed-size chunks (called pages)

• Divide physical memory into pages of the same size

• Any virtual page can be located at any physical page

• Translation box converts from virtual pages to physical pages

012345

0123

012345678910111213

Translation

Virtual Page #

Physical Page #

0x0000

0x6000

0x0000

0x4000

0x0000

0xE000


Paging and Fragmentation

• No external fragmentation because all pages are the same size» don’t have to rearrange pages

• Sometimes there is internal fragmentation because a process doesn’t use a whole page» some space wasted at the end of a page» better than external fragmentation


Page Tables

Page TableVirtual

Page #

Physical

page #

virtual addressVPN

Offset

physical address

PPN

Offset

• A page table maps virtual page numbers to physical page numbers

• Lots of different types of page tables» arrays, lists, hashes

Flat Page Table

• A flat page table uses the VPN to index into an array

• What's the problem? VPN

PPN

Page Table

56213109

012345678910111213

012345

VPN Offset

4 100

Memory


Flat Page Table Evaluation

• Very simple to implement• Don't work well for sparse address spaces

» code starts at 0x00400000, stack starts at 0x7FFFFFFF

• With 4K pages, this requires 1M entries per page table » must be kept in main memory (can't be put on disk)

• 64-bit addresses are a nightmare (4 TB)• Addressing page tables in kernel virtual memory

reduces the amount of physical memory used


Multi-level Page Tables

• Use multiple levels of page tables» each page table entry points to another page table» the last page table contains the physical page

numbers (PPN)

• The VPN is divided into » Index into level 1 page» Index into level 2 page» …

Multi-level Page Tables

012345678910111213

L1 Page Table

NO

VPN Offset

3 1002

0123

MemoryL2Page Tables


Multi-Level Evaluation

• Only allocate as many page tables as we need--works with the sparse address spaces

• Only the top page table must be in pinned in physical memory

• Each page table usually fills exactly 1 page so it can be easily moved to/from disk

• Requires multiple physical memory references for each virtual memory reference» TLB masks most of this

Inverted Page Tables

• Inverted page tables hash the VPN to get the PPN

• Requires O(1) lookup• Storage is proportional

to number of physical pages being used not the size of the address space

Hash

Table

VPN Offset

Inverted Page Table Memory

8/25/2014cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington1 Memory...

Documents

Transcript of 8/25/2014cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington1 Memory...