================ Start Lecture #16 ================
Midterm Exam Reviewed
4.2.2: Memory Management with Linked Lists
Each item on list gives the length and starting location of the
corresponding region of memory and says whether it is a Hole or Process.
The items on the list are not taken from the memory to be
used by processes.
Keep in order of starting address.
Merge adjacent holes.
Memory Management using Boundary Tags
Use the same memory for list items as for processes.
Don't need an entry in linked list for blocks in use, just
the avail blocks are linked.
The avail blocks themselves are linked, not a node that points to
an avail block.
When a block is returned, we can look at the boundary tag of the
adjacent blocks and see if they are avail.
If so they must be merged with the returned block.
For the blocks currently in use, just need a hole/process bit at
each end and the length. Keep this in the block itself.
We do not need to traverse the list when returning a block can use
boundary tags to find predecessor.
See Knuth, The Art of Computer Programming vol 1.
MVT also introduces the “Replacement Question”
That is, which victim should we swap out?
Note that this is an example of the suspend arc mentioned in process
We will study this question more when we discuss
demand paging in which case
we swap out part of a process.
Considerations in choosing a victim
- Cannot replace a job that is pinned,
i.e. whose memory is tied down. For example, if Direct Memory
Access (DMA) I/O is scheduled for this process, the job is pinned
until the DMA is complete.
- Victim selection is a medium term scheduling decision
- A job that has been in a wait state for a long time is a good
- Often choose as a victim a job that has been in memory for a long
- Another question is how long should it stay swapped out.
- For demand paging, where swaping out a page is not as drastic as
swapping out a job, choosing the victim is an important memory
management decision and we shall study several policies,
- So far the schemes presented so far have had two properties:
- Each job is stored contiguously in memory. That is, the job is
contiguous in physical addresses.
- Each job cannot use more memory than exists in the system. That
is, the virtual addresses space cannot exceed the physical address
- Tanenbaum now attacks the second item. I wish to do both and start
with the first.
- Tanenbaum (and most of the world) uses the term “paging” to mean
what I call demand paging. This is unfortunate as it mixes together
- Paging (dicing the address space) to solve the placement
problem and essentially eliminate external fragmentation.
- Demand fetching, to permit the total memory requirements of
all loaded jobs to exceed the size of physical memory.
- Tanenbaum (and most of the world) uses the term virtual memory as
a synonym for demand paging. Again I consider this unfortunate.
- Demand paging is a fine term and is quite descriptive.
- Virtual memory “should” be used in contrast with physical
memory to describe any virtual to physical address translation.
** (non-demand) Paging
Simplest scheme to remove the requirement of contiguous physical
Example: Assume a decimal machine with
page size = frame size = 1000.
- Chop the program into fixed size pieces called
pages (invisible to the programmer).
- Chop the real memory into fixed size pieces called page
frames or simply frames.
- Size of a page (the page size) = size of a frame (the frame size).
- Sprinkle the pages into the frames.
- Keep a table (called the page table) having an
entry for each page. The page table entry or PTE for
page p contains the number of the frame f that contains page p.
Assume PTE 3 contains 459.
Then virtual address 3372 corresponds to physical address 459372.
Properties of (non-demand) paging.
- Entire job must be memory resident to run.
- No holes, i.e. no external fragmentation.
- If there are 50 frames available and the page size is 4KB than a
job requiring <= 200KB will fit, even if the available frames are
scattered over memory.
- Hence (non-demand) paging is useful.
- Introduces internal fragmentation approximately equal to 1/2 the
page size for every process (really every segment).
- Can have a job unable to run due to insufficient memory and
have some (but not enough) memory available. This is not
called external fragmentation since it is not due to memory being fragmented.
- Eliminates the placement question. All pages are equally
good since don't have external fragmentation.
- The replacement question remains.
- Since page boundaries occur at “random” points and can change from
run to run (the page size can change with no effect on the
program--other than performance), pages are not appropriate units of
memory to use for protection and sharing. This is discussed further
when we introduce segmentation.
- Each memory reference turns into 2 memory references
- Reference the page table
- Reference central memory
- This would be a disaster!
- Hence the MMU caches page#-->frame# translations. This cache is kept
near the processor and can be accessed rapidly.
- This cache is called a translation lookaside buffer (TLB) or
translation buffer (TB).
- For the above example, after referencing virtual address 3372,
there would be an entry in the TLB containing the mapping
- Hence a subsequent access to virtual address 3881 would be
translated to physical address 459881 without a memory reference.
Choice of page size is discuss below.