Contiguous Memory Management and External Fragmentation Summary of

Contiguous Memory Management and External Fragmentation

Summary of Contiguous memory Management and the Free Space List (FSL) • Contiguous memory management means that the physical address space of a process in main memory must be one contiguous block • The key OS data structure involved in contiguous memory management is the free space list, the list of free (available, unused) blocks of physical memory • The FSL must be managed according to some policy • All FSL policies (e. g. , first-fit, best-fit, worst-fit) eventually lead to external fragmentation MSJ-2

External Fragmentation • External fragmentation refers to memory external to any process that is unusable because it’s in fragments too small to be useful • Note: The distinction between a small but possibly usable hole in memory and an unusable fragment is not intended to be technically precise; we just say that memory has become too fragmented when the OS cannot admit some new process despite the fact that there is plenty of unused memory available, just scattered all over in fragments too small for typical new processes MSJ-3

External Fragmentation with Best Fit main memory • Note that just because process #8 can’t be OS and • OS processes, being theon first ones created, Let’s see how best-fit works some random series of arrivals admitted, that doesn’t mean that another processes • When processplaced #1 terminates, itsof memory is Because we’re doing best-fit, are usually at one end the terminations of processes of random sizes (smaller) process can’t still bethe admitted, reclaimed Process #4 process #4 went into smallest process #9 • Process #2 terminates process #1 #4 But memory is still fragmented, meaning memory, with low memory being the process provided there’s a hole big enough terminates available hole thatmay wassearched large enough • First, the FSL must be to see if that some new processes not be most common choice • It’s memory is reclaimed and As there’s new processes are created, theyit must be admitted byprocess #7 • • But no guarantee that there will there any adjacent holes can be admitted, despite the fact that there is, in merged with thememory hole above it with the textbook shows low at the • Our long term scheduler which must check ever again be a hole big enough for process #2 merged with (inmemory this case, no) process #8 total, enough unused for them top of its figures, addresses increasing as memory to see if there is sufficient space for process #8; manager starvation is possible • Then the new hole is inserted down the picture, so in I’llthe do. FSL the one newmoves process #6 same thingmanager in this diagram process #3 Process #3 • The memory searches the free space list (FSL) When #6 terminates, • When process #8 applies forprocess admission, #10 terminates to find a hole that is of sufficient size process #8 can be admitted memory has become too fragmented Thissum animation “best-fit” • • The total of illustrates all free space is more. FSL thanlogic the process #8 demand, but a process needs process #5 its physical address space to be contiguous and there is no single (contiguous) hole big enough to admit process #8 MSJ-4

External Fragmentation with Worst-Fit main memory Let’s look at the same sequence of arrivals and terminations as for the previous best-fit example, but let’s see what happened if we do worst-fit for our FSL OS processes process #1 process #2 process #6 #3 process #8 process #5 process #4 process #7 process #9 MSJ-5

Summary of FSL Policies for Contiguous Memory Management • Regardless of what your textbook seems to imply, all FSL policies (including worst-fit) are subject to external fragmentation • Some delay serious problems longer than others, but everybody eventually succumbs • It has nothing to do, really, with the specific FSL policy; the problem is intrinsic to contiguous memory management

So What’s the Answer? § Palliative: Quantized allocation § Curative: § Compaction § Paged memory management MSJ-7

Internal Fragmentation (and Then Quantized Allocation) § Suppose we’re doing best-fit and a process needs an allocation of 1599810 bytes and the smallest hole we have on the FSL bigger than 1599810 is 1600310 bytes § There’s no really point at all in giving the process the 1599810 bytes it wants and then creating a new hole of 5 bytes and inserting it (a 5 -byte hole) into the FSL § Instead, let’s just give the process the whole of 1600310 bytes § The 5 extra bytes is now referred to as internal fragmentation: “wasted” memory that is internal to the allocated physical address space for some process rather than sitting pointlessly on the list of available memory ─ i. e. , the FSL, the list of available memory, which, by definition, must be external to all processes MSJ-8

Quantized Allocation § Next, let’s “quantize” our memory allocation policy § All memory will be allocated in “chunks” or quanta of some fixed size § If our quantum is 1 K bytes for example, every process’s physical address space will be some integer multiple of 1 K and every hole on the FSL will also be some integer multiple of 1 K, the smallest possible hole being simply 1 K § So, for example, a process that needed 1500210 bytes would be given 16 K of memory from the smallest hole ≥ 16 K in size MSJ-9

Quantized Allocation (cont’d) § Quantification doesn’t solve external fragmentation, but it lessens some of its ill effects and can thus postpone “the day of reckoning” e. g. , we won’t fill up the FSL with absurdly small holes that still take time to get through when we search the FSL § So we can avoid the slow down that comes with searching an overly long FSL but we still can’t stop external fragmentation from eventually accumulating too many small holes, § Even if the quantum is, for example, 1 K, so that all holes are a multiple of 1 K, how useful is a 1 K fragment? MSJ-10

Internal Fragmentation Again § Can we avoid external fragmentation by making our quantum really large, say 128 K, so no hole will ever be smaller than 128 K? § Maybe, but … § Now our internal fragmentation will start to really hurt MSJ-11

Average Internal Fragmentation § The average internal fragmentation is ½ quantum per process § Suppose our quantum is 128 K bytes: § A process that needs 128, 003 bytes will be given 256, 000 bytes, “wasting” 127, 997 bytes to internal fragmentation § A process that needs 383, 995 bytes will be given 384, 000 bytes ( = 3 x 128, 000 bytes), wasting only 5 bytes § On the average, half the processes will waste more than ½ a quantum, half will waste less; overall, the average internal fragmentation will be ½ per quantum per process § If there are 500 processes and the quantum is 128 K, internal fragmentation will eat up (on average) 500 x 64 K = 32 MBytes § So too big a quantum to try to avoid external fragmentation will waste too much to internal fragmentation MSJ-12

So What’s the Answer? § Palliative: Quantized allocation § Curative: § Compaction § Full compaction § Partial compaction § Paged memory management MSJ-13

Compaction § Compaction is the only complete cure for external fragmentation without giving up on contiguous memory management altogether, which we will eventually do but first you have to suffer through compaction § Why? Academic tradition (I suffered, so you have to suffer ; -) MSJ-14

Compaction § To compact memory is to relocate processes so as to consolidate all the holes into one big hole to make room for a new process that otherwise couldn’t be admitted because of external fragmentation process #8 § Compaction can be total, as we just saw, where every process not already “snug at the end” gets relocated, or … main memory OS processes process #7 process #6 process #5 MSJ-15

Compaction (cont’d) § It can be “partial”: Just relocate enough processes to make a hole big enough for the new process, don’t consolidate all the holes (unless necessary) § There are several issues to consider in either case main memory OS processes process #7 process #8 process #6 process #5 MSJ-16

Compaction Requires Execution Time Binding Which Requires an MMU Extra Hardware The address 0 x 00 f 32 here can’t be a physical address or it would behave incorrect If this were a physical address, it would to theearlier relocation ofatprocess #7 or and the have beenafter bound i. e. , compile would have no wayittonow: correct it load time. OS and we can’t rebind • We obviously can’t recompile a process in middle it’s execution So the if the OS isof going to have to dynamically Here’s old friend, someissort relocate a process during itsour execution, which • And the execution environment doesn’t of jump or transfer what compaction requires, the addresses in the include the relocation flags used by instruction the programs in load memory to be left logical addresses loader at timehave they’re behind in andthe weload mustmodule be doing on execution the disk time binding, which requires an MMU main memory OS processes process #7 0 x 2 a 00 f 32 process #6 process #5 MSJ-17

Other Issues with Compaction main memory Physically copying all the processes in memory to new locations is generally going to be too timeconsuming for a real-time system OS processes process #7 process #6 process #5 MSJ-18

Other Issues with Compaction (cont’d) main memory § Partial compaction can reduce the number of processes relocated and thus the time required § But: § Since we are still left with some degree of external fragmentation, we’ll have to run the compactor again sooner than if we had done a full compaction § The algorithm to decide which process(es) to relocate can get fairly complex and hence time consuming in its own right the tradeoff, obviously being between clever but time consuming algorithms that efficiently reduce the external fragmentation and simpler algorithms that don’t clean up the fragmentation as much or as quickly OS processes process #7 process #6 process #5 MSJ-19

Giving Up the Requirement for a Process’s Physical Address Space to be Contiguous § Palliative: Quantized allocation § Curative: § Compaction § Full compaction § Partial compaction § Paged memory management MSJ-20