Memory Management Five Requirements for Memory Management to satisfy: –Relocation Users generally don’t know where they will be placed in main memory May want to swap in at a different place –Must deal with user pointers Generally handled by hardware –Protection Prevent processes from interfering with the O.S. or other processes Often integrated with relocation –Sharing Allow processes to share data/programs –Logical Organization Support modules, shared subroutines –Physical Organization Manage mem disk transfers
Techniques Table 7.1, page 306 Fixed Partitioning –Divide memory into partitions at boot time, partition sizes don’t change –Simple but has internal fragmentation Dynamic Partitioning –Create partitions as programs loaded –Avoids internal fragmentation, but must deal with external fragmentation Simple Paging –Divide memory into equal-size pages, load program into available pages Pages do not need to be consecutive –No external fragmentation, small amount of internal fragmentation
Techniques Simple Segmentation –Divide program into segments Each segment is contiguous, but different segments need not be –No internal fragmentation, some external fragmentation Virtual-Memory Paging –Like simple paging, but not all pages need to be in memory at one time –Allows large virtual memory space –More multiprogramming, overhead Virtual Memory Segmentation –Like simple segmentation, but not all segments need to be in memory at one time –Easy to share modules –More multiprogramming, overhead
Fixed Partitioning Memory is divided into a set of partitions, each holds one program May have same or different sizes –(Figure 7.2, page 307) Equal-sized partitions –Program may be too large for one partition Programmer must handle overlays –Program may not be big enough to need a full partition Results in internal fragmentation
Fixed Partitioning Variable-sized partitions –Can fit partition size to program size –Placement Which partition do we use? –Want to use smallest possible partition –What if there are no large jobs waiting? Can have a queue for each partition size, or one queue for all partitions Easy to implement Limits degree of multiprocessing –Fixed at start time by # of partitions Tends to use memory poorly, especially for small programs (internal fragmentation) –Will work if the job sizes can be predicted in advance Used by IBM OS/MFT, obsolete
Dynamic Partitioning Create a new partition for each program Only allocate space required Tends to create “holes” as processes are swapped in and out (external fragmentation) Fig 7.4: pg. 310
Dynamic Partitioning Tends to generate small holes in memory (external fragmentation) Compaction –Shifting processes so all of the available memory is in one block –Requires processor time to move items around in memory –Requires relocation hardware that can handle the change in addresses Cannot easily find all possible addresses in the program Need to move program without changing user addresses
Dynamic Partitioning Placement –Best-Fit: Find the smallest available block that will hold the program Tends to produce a lot of small blocks –Use 30K block for 28K program, leaves 2K –First-Fit: Find the first block that is large enough (regardless of size) May leave small blocks at the beginning, larger blocks at the end of memory –Next-Fit: Like First-Fit, but start from the last allocation instead of the start Tends to break up large blocks at the end of memory that First-Fit leaves alone –Comparison: Figure 7.5, page 312 –First-Fit generally best, fastest Replacement Algorithm –Who gets swapped out? (Chapter 8)
Buddy System Tries to allow a variety of block sizes while avoiding excess fragmentation Blocks generally are of size 2 k, for a suitable range of k Initially, all memory is one block All sizes are rounded up to 2 s If a block of size 2 s is available, allocate it Else find a block of size 2 s+1 and split it in half to create two buddies If two buddies are both free, combine them into a larger block Largely Replaced by paging –Seen in parallel systems and Unix kernel memory allocation
Buddy System Example Figure 7.6, page 314 Representation of used and free nodes as a tree: Figure 7.7, page 315
Relocation Not a major problem with fixed- sized partitions –Easy to load process back into the same partition Otherwise need to deal with a process loaded into a new location Memory addresses may change –When loaded into a new partition –If compaction is used Addresses –Logical Addresses As seen by the program Often set as relative to the program start –Physical Addresses As seen by memory Hardware does address conversion
Base/Bounds Relocation Figure 7.8, page 317 Base Register –Holds beginning physical address –Add to all program addresses Bounds Register –Used to detect accesses beyond the end of the allocated memory –May have length instead of end address –Provides protection to system Easy to move programs in memory –Change base/bounds registers Largely replaced by paging
Paging Divides memory into small (4K or less) pieces of memory (frames) Logically divide program into same-size pieces (pages) Use a page table to map the pages of the current process to the corresponding frames in memory Example (Figure 7.9, page 318):
Paging Continued Page Tables for previous example (Figure 7.10, page 319) Page size typically a power of 2 to simplify the paging hardware –Example (16-bit address, 1K pages) Top 6 bits (010101)= page # Bottom 10 bits ( ) = offset within page –Common sizes: 512 bytes, 1K, 4K
Segmentation Program views memory as a set of segments of varying sizes –Easy to handle growing data structures –Easy to share libraries, memory –Privileges can be applied to a segment –Programs may use multiple segments Have a segment table –Beginning address –Size –Present, Modified, Accessed bits –Permission/Protection bits