Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
35 Cards in this Set
- Front
- Back
Uniprogramming |
One process executes at a time OS protected from process by address checking Process executes in a contiguous segment of memory |
|
Multiprogramming |
Mimic uniprogramming w/ swapping Swap entire process to disk when blocked Swap entire process from disk to run |
|
Multiprogramming requirements |
Transparency: need for multiple processes to coexist in memory Safety: processes should not be able to corrupt each other/kernel Efficiency: performance of CPU should not be degraded badly due to sharing |
|
Process relocation/protection: static |
OS adjusts process address at load time to reflect its location in memory |
|
Dynamic process relocation/protection |
Hardware adds base register to virtual address in order to get physical addresses Hardware compares virtual address w/ bound register |
|
Process relocation/protection: memory allocation strategies |
Strategies: First fit: begin storing in the very first free block found that will fit
Best fit: places process in the smallest available block found to fit
Worst fit: places process in the largest available block that will fit |
|
Process relocation/protection: making more room |
Compaction: relocate programs to merge free space Swapping: preempt processes and reclaim their memory |
|
Process relocation/protection: advantages |
Processes can move during execution Protection is easy Simple hardware |
|
Process relocation/protection: drawbacks |
External and internal fragmentation Sharing is near impossible Can't grow stack/heap as needed Low degree of multiprogramming Hardware slowdown Permissions the same for entire address space |
|
Memory segmentation |
Supporting an array of base and bound addresses for processes |
|
Memory segmentation traits |
Segment sharing Zero-on-reference Copy-on-write |
|
Memory segmentation:advantages |
Can share code/data segments between processes Can protect code segment from being overwritten Can transparently grow stack/heap as needed Can detect if need to Copy-on-write |
|
Memory segmentation: drawbacks |
Need to find memory chunks of particular size May need to compact memory to make room External fragmentation Limited number of segments |
|
Paged memory |
Memory is divided into fixed sized chunks called pages Virtual pages in virtual address space Page frames in the physical memory |
|
Page frames |
Physical memory is partitioned into equal sized page frames |
|
Virtual pages |
A process's virtual address space is partitioned into equal sized virtual pages Equivalent page size to physical pages frame size |
|
Virtual to physical pages |
Virtual pages map to page frames Virtual pages are contiguous in the virtual address space, but page frames are arbitrarily located in physical memory Not all pages are mapped at all times |
|
How are virtual addresses translated into physical addresses? |
Page table |
|
Page table |
An array of mapping entries |
|
Paged table traits |
One table per process Stored in physical memory One page table entry for each virtual page |
|
Memory paging: advantages |
Elimination of external fragmentation Easy to allocate and deallocate memory to/from processes Allows processes to use more memory than physical amount of memory Share memory between processes |
|
Memory paging: issues |
Memory consumption Page size Sparse address spaces: many separate segments |
|
Memory efficient paging: inverted page table |
Mapping physical address space instead of virtual address space One entry for each physical page Size if page proportional to physical memory |
|
Speed efficient paging: issue |
Performance For every memory access, two( or more) accesses Locality of reference |
|
How to avoid having to access page table |
Translation lookaside buffer |
|
Translation lookaside buffer |
Cache of recent virtual page to physical frame translations |
|
TLB management: hardware |
Hit: check valid bit Check access permission Return pfn Miss: hardware walks to page table Loads the PTE into TLB Goto TLB hit |
|
TLB management:software |
Hit: same as hardware Miss: trap to kernel Software walks page table and loads PTE into TLB Resume to faulting instruction |
|
TLB issue |
Large contiguous memory |
|
Superpage |
A set of contiguous, aligned pages |
|
TLB issues |
Large contiguous memory Context switch Consistency |
|
Demand paging |
Illusion of infinite memory, available to every process Only bring in pages actually used Only keep frequently used pages in memory |
|
Demand paging: performance |
Processes exhibit Locality of reference Temporal Locality: I'd a process accesses an item in memory, it will tend to reference the same item again soon Spatial Locality: if a process access an item in memory, it will tend to reference an adjacent item soon |
|
Demand paging: page frame allocation |
In event memory is full, Old page is evicted and all TLB entries and PTE associated w/ it are blanked |
|
Page frame eviction policies |
Random: randomly choose a page to evict FIFO: First in, first out. Replace the page that has been loaded the longest time MIN: God's algorithm. Replace the page that will not be used for the longest time in the future LRU: replace the page that has not been used for the longest time in the past |