ICS 145B -- L. Bic1 Project: Main Memory Management Textbook: pages ICS 145B L. Bic

ICS 145B -- L. Bic2 Assignment Implement a main memory manager for variable size partitions using linked lists (section 7.2.2) Compare different allocation strategies (section 7.3) using simulation

ICS 145B -- L. Bic3 Variable Partitions -- review Memory not partitioned a priori Each request is allocated portion of free space Memory = Sequence of variable-size blocks –Some are occupied, some are free (holes) –External fragmentation occurs Adjacent holes (right, left, or both) must be coalesced to prevent increasing fragmentation Figure 7-6

ICS 145B -- L. Bic4 Linked List Implementation 1 Type/Size tags at the start of each Block Holes (must be sorted by physical address) contain links to predecessor hole and to next hole Checking neighbors of released block, e.g C below: –Right neighbor (easy): Use size of C –Left neighbor (clever): Use sizes to find first hole to C’s right, follow its predecessor link to first hole on C’s left, and check if it is adjacent to C. Figure 7-7a

ICS 145B -- L. Bic5 Linked List Implementation 2 Better solution: Replicate tags at end of blocks Checking neighbors of released block C: –Right neighbor: Use size of C as before –Left neighbor: Check its (adjacent) type/size tags Holes do not need to be sorted in memory –A new hole is simply appended to the head or tail of the list Figure 7-7b

ICS 145B -- L. Bic6 Allocation Strategies Problem: Given a request for n bytes, find hole ≥ n Constraints: –Maximize memory utilization (minimize “external fragmentation”) –Minimize search time Search Strategies (section 7.3): –First-fit: Always start at same place. Simplest. –Next-fit: Resume search. Improves distribution of holes. –Best-fit: Closest fit. Avoid breaking up large holes. –Worst-fit: Largest fit. Avoid leaving tiny hole fragments

ICS 145B -- L. Bic7 Simulated Main Memory define a character array of size mem_size char mm[mem_size]; each character represents one byte of memory represent each tag and size field as an unsigned integer (4 bytes) –use type casting to read/write integers into mm holes may be linked using either: actual pointers (8 bytes) integers (4 bytes) as indices into array mm –use type casting to read/write int/ptr into mm

ICS 145B -- L. Bic8 The User Interface void *mm_init (int mem_size) –initialize character array mm to be a single hole void *mm_request(int n) –analogous to function malloc() –request a block of n consecutive bytes –return pointer to first usable byte (or mm index of first usable byte) void mm_release(void *p) –analogous to function free() –releases a previously requested block back to mm

ICS 145B -- L. Bic9 The Simulation Experiment driver Main Memory Manager parameters invoke functions results (analyze and plot) invoke driver, which: –generates streams of requests and releases using parameters –repeatedly invokes request/release functions –gather statistics in files for each request repeat for different parameters and different allocation strategies analyze, plot, describe results

ICS 145B -- L. Bic10 The Simulation Experiment assume steady state: –there is an unbounded queue of requests –requests are satisfied until no hole large enough exists –memory does not change until next release what to vary: –average request size n (relative to total memory size) what to measure: –average memory utilization –average search time

ICS 145B -- L. Bic11 Outline of Driver start in a steady state (memory already has full blocks and holes)start in a steady state (memory already has full blocks and holes) fo for (i=0; i<sim_step; i++) { do { get size n of next request mm_request(n) } while (request successful) record memory utilization select block p to be released select block p to be released mm_release(p) }

ICS 145B -- L. Bic12 Driver Details how to generate stream of requests –assume Gaussian distribution –generate each new request size using: n = gauss(a, d) where a is the average request size and d is the standard deviation –discard values outside of valid memory sizes –a and d are the input parameters to be varied relative to memory size

ICS 145B -- L. Bic13 Driver Details choosing a block to release –assume memory resident time is independent of block size and is distributed uniformly: select a block at random –how: driver must keep track of all allocated blocks use a linked list determine number of list elements k choose a random number p between 1 and k release block recorded at position p of list

ICS 145B -- L. Bic14 Driver Details gathering performance data –average memory utilization determine utilization at each iteration –fraction of used memory: add up block sizes, divide by total memory size (include tags in size?) –ratio holes/blocks: count # holes and #blocks (groups only) compute averages does 50%-rule hold? does formula for computing f hold? (pg. 223, groups only) –average search time instrument mm_request() to count # holes examined

ICS 145B -- L. Bic15 Driver Details starting in steady state –using the following loop, fill memory with random-size requests: do { get size n of next request mm_request(n) } while (request successful) –randomly choose 1/3 of all blocks and release them –repeat the above two steps several times

ICS 145B -- L. Bic16 Summary of tasks design and implement memory manager –mm_init, mm_request, mm_release functions –mm_request must support at least: two strategies if working alone three strategies if in a group design and implement driver –accept parameters (mem_size, a, d, strategy, sim_step) –run simulation experiment, store results in a file determine under which conditions a given strategy performs better than another –vary one parameter each time –plot curves –interpret observations