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
Let’s • see
OS
admitted, how best-fit
processes,
that doesn’tbeing
works
meanthe onfirst
some
that ones created,
random
another series of OS and
arrivals
• When Because
process
are usually we’re
#1
placed doing
terminates,
atofone best-fit,
endits memory
ofsizes
the is processes
terminations
(smaller)
reclaimed of processes
process can’t still random
be admitted,
But process
memory,
memory • is #4
Process
with went
still
low #2 into the being
terminates
fragmented,
memory meaningProcess
smallest the #4 process #9
process #1
#4
provided there’s
• First,
available
the a hole
hole
FSL big
thatmay
must enough
wassearched
be large terminates
enough
to see if process
that
• •But
most
some
As there’s
new •
noIt’s
common
new memory
processes
choice
guarantee
processes are is
that
created, reclaimed
not
there
be
theywillmustand be admitted byprocess #7
admitted, there are
despiteanytheadjacent
factlow thatholes
there it can
is,checkbe
inthe
the
ever • Our
long
again term
be merged
textbook
a shows
scheduler
hole with
big the
which
enough hole
memory
must
for above at it with the
total, merged
enough with (inmemory
unused this case, forno)
them process #8 process #2
processtop
memory of
#8; its figures,
manager
starvation addresses
to see
is increasing as
if there is sufficient space for
possible
the one• Then
new moves the down
process new hole is inserted
the picture, so inI’llthe
doFSLthe
• same thingmanager
in this diagram process process #6
• When process #8 applies
The memory searches
When forprocess theProcess
admission, free #3
space
#6 terminates,
#10
list (FSL)process #3
to find a hole
memory has become too that is of sufficient
process terminates
size
#8 can be admitted
fragmented
• •The
Thissum animation
total of illustrates
all free space “best-fit”
is moreFSL 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
OS
Let’s look at the same sequence of arrivals and processes
terminations as for the previous best-fit example,
but let’s see what happened if we do worst-fit for process #1
our FSL
process #2

process #6
#3

process #8 process #4

process #7
process #5
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 hole 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 1K bytes for example, every process’s

physical address space will be some integer multiple of 1K and
every hole on the FSL will also be some integer multiple of
1K, the smallest possible hole being simply 1K

 So, for example, a process that needed 1500210 bytes would be

given 16K of memory from the smallest hole ≥16K 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, 1K, so that all holes are a
multiple of 1K, how useful is a 1K fragment?

MSJ-10
 Internal Fragmentation Again

 Can we avoid external fragmentation by making our quantum

really large, say 128K, so no hole will ever be smaller than 128K?

 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 128K 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 128K, internal
fragmentation will eat up (on average) 500 x 64K = 32MBytes
 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
main
memory
 To compact memory is to relocate processes so OS
processes
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
process #7
fragmentation
 Compaction can be total, as we just saw, whereprocess #8
every process not already “snug at the end” gets
process #6
relocated, or …

process #5

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

process #6

process #5

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

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

process #6

process #5

MSJ-18
 Other Issues with Compaction (cont’d)
main
memory

 Partial compaction can reduce the number of OS

processes
processes relocated and thus the time required
 But:
 Since we are still left with some degree of external process #7
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 process #6
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 process #5
and simpler algorithms that don’t clean up the
fragmentation as much or as quickly
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