Physical Memory Management
Physical Memory
- byte addressable (can refer to each byte in memory), limited size
- ~200 cycles access latency (as a reference, common instrs within 7 cycles)
- a process's code and data needs to be in memory to execute
Physical Memory Management
- another resource allocation problem: limited physical memory, multiple processes
- so how do we allocate memory?
- basic case: support one process using physical memory at a time
- give the entire physical memory to the process
- no translation needed, process's address = physical address
- simple, no performance overhead
- what if a process is blocked on I/O?
- how to enforce kernel/user separation?
- what if process needs more memory than physically available?
- multiprocessing case: processes sharing physical memory
- attempt 1
- place processes' memory in disjoint sections of physical memory
- each process's memory is contiguous in physical memory
- should processes access physical memory directly?
- are processes guaranteed to be placed in the same location within physical memory every time?
- how would we implement fork if processes access physical memory directly?
- address translation support
- hw support: base and bound registers
- processes may require different amount of physical memory
- fragmented physical memory, poor utilization
- processes may need more memory as they run
- how would we support memory growth?
- how many processes may share physical memory?
- depending on how much memory each process needs
- attempt 2
- goals: better memory utilization, more sharing of physical memory, flexible growth
- strategies
- a process can't access all of its memory at once, only load in memory as they are accessed (more sharing)
- a process's memory only needs to be contiguous in virtual memory, not physical memory (flexible growth)
- instead of allocating variable sized physical memory, allocate in fixed sized pages (less fragmentation)
- paging
- how would we support address translation for paging?