Paradigm Shifts in Memory Usage

1
Paradigm Shifts in Memory Usage

• Multiprogramming
• CPU much faster than I/O devices, so more
  desirable to execute one program while another
  one waits for I/O
• Exp. Disk access 10ms 10ms time for 5M
  instructions on a 2GHz CPU (500 MIPS)
• Problems created
• Where to place pieces of processes?
• How to keep malicious/buggy processes from
  reading/writing other processes memory space
  while also allowing sharing?
• All memory techniques address ever more
  sophisticated specializations of these problems

2
Paradigm Shifts in Memory Usage

• Indirect addressing
• Address generated by process is not immediately
  interpreted as a physical address address might
  undergo some check and/or change
• Check against base limit registers
• Change via address scrambling must remain
  within physical address space
• Change via mapping from a virtual address space
  to a physical address space
• Need hardware support since memory reference must
  be very fast!
• Several forms, or degree, of indirect addressing
  possible
• Indirect address is part of but not identical to
  virtual memory

3
Memory Hierarchy

• Small amount of very fast, volatile, and
  expensive memory cache
• Medium speed, medium size, volatile main memory
• Lots of cheap, slow access, non-volatile disk
  storage

4
Progression of Memory Management Solutions (some
historical)

• Single program in memory programs executed one
  at a time, in control of entire machine
• No privileged mode
• OS in RAM or ROM
• Device drivers in ROM BIOS (Basic I/O System)
• Memory was small and hardware was very expensive,
  so efficient use of hardware was important

5
Progression of Memory Management Solutions (some
historical)

• Problem 1 Memory unused during I/O
• Multiprogramming solution
• Divide memory into fixed-size partitions
• Place separate programs in separate, fixed-size
  and fixed-location partitions
• Run one program while another does I/O
• Issues
• What should partition size be? Variable?
• Load which programs into which partition?
• Best to match program and partition size, but not
  let any program wait too long

6
Progression of Memory Management Solutions (some
historical)

• Problem 2 Partition addresses hard-coded into
  programs resulted in unused memory when one
  partition is not in use while another has
  programs waiting. When are physical addresses
  bound?
• Solution Relocation
• Load-time relocation via relocating loader
• Linker specifies which program addresses can be
  relocated and which cannot
• No special hardware required OS (loader) changes
  the relocatable addresses to reflect the
  partitions start address into which program was
  loaded.
• Exp. Partition 2 starts at 200K, then all program
  addresses rewritten to be 200K addr.

7
Progression of Memory Management Solutions (some
historical)

• Solution Relocation
• Run-time relocation via relocation register or
  base register
• When process is scheduled, base register is
  loaded with address of partition where program
  was started
• Base register is invisible to user program
• Every memory address accessed by process has base
  register automatically added
• Needs special hardware (base register)
• light form of indirect addressing
• More flexible than load-time relocation

8
Progression of Memory Management Solutions (some
historical)

• Problem 3 Need to protect programs from each
  other
• Solution limit register
• Limit register is loaded with address of end of
  partition into which program was loaded
• Program cannot access memory space beyond limit
  address
• Use both base and limit registers to bound the
  memory space available to program
• Problem 4 Lack of flexibility and waste from
  fixed-location and/or fixed size partitions
• Compaction of variable size partitions
• Much smaller fixed-size pages and indirect
  addressing

9
Progression of Memory Management Solutions (some
historical)

• Problem 5 Under multiprogramming, there is still
  memory unused during I/O
• Solution swapping of process entire memory to
  disk
• Before multiprogramming, all memory was wasted
  during I/O. Before swapping, one process memory
  space was wasted
• Problem 6 Programs may be larger than physical
  memory
• Solution virtual memory
• Indirect addressing
• Demand paging
• Problem 7 Several processes may store a copy of
  the same library code in its memory space
• Solution shard libraries and dynamic linking

10
Progression of Memory Management Solutions (some
historical)

• All modern computer systems use advanced form of
  virtual memory
• Some of the now-outdated techniques (relocation)
  for placing processes within the machines memory
  space are still used for placing objects within a
  single process address space and for managing
  pools of storage (on disk or in memory)

11
Swapping

• Movement of entire processes in and out of memory
• Processes that are swapped out are stored on disk
  in a designated swap space
• For efficiency, swap space is allocated
  contiguously in a separate partition on disk
• Necessitated by timesharing
• Inactive process is swapped out
• Process might be inactive while waiting for I/O
• When processes are swapped back in, they may no
  longer be in same partition
• Need to relocate addresses how is this best
  done?
• Swapping can result in hole of free space
• Merge holes through memory compaction

12
When is Swapping Used?

• Makes sense only when memory is precious do many
  swaps in order to free some memory
• Naïve implementation leads to very high context
  switching overhead, so try to have all processes
  in the ready queue swapped in
• Still used in virtual memory systems only as an
  emergency procedure when many page frames must be
  freed quickly
• light form of swapping is used to swap in and
  out only portions of a process these portions
  are stored as pages in memory

13
Fixed vs. Variable-Size Partitions

• Fixed-size partitions leads to unused memory
  inside the partition (internal fragmentation)
  when processes do not fit exactly into partition
• Solution allow variable-size partitions that are
  defined by the size of the process
• Start address of partition must also vary.
  Otherwise, there will be unused holes between
  partitions (external fragmentation)
• Need to ensure that there is room for process to
  grow
• When swapping in a process, need to quickly find
  a partition that will fit the process (several
  different strategies possible)
• Need to quickly and easily compact adjacent areas
  of unused memory
• Requires keeping track of free vs. used areas of
  memory

14
Keeping Track of Free/Used Memory

• Bitmap of allocated memory units
• Linked-list of free/used partitions
• Buddy system used by Linux

15
Bitmap of Free/Used Memory

• Each bit in the bitmap corresponds to 1 memory
  allocation unit
• Bit 0 if free
• Bit 1 if in use by a process
• Smaller allocation units larger bitmap required
• Larger allocation units more wasted space
  possible
• Advantage - Simple to implement
• Disadvantages
• To bring in a process of k allocation units into
  memory, memory manager must find a contiguous
  section of k bits in the bitmap. This search is
  slow!
• Difficult to do compaction of memory, but
  neighboring holes are automatically merged

16
Linked-list of Free/Used Partitions

• Each element in the linked list is a partition in
  use by a process or is a hole of unused memory
  space
• Several implementations possible
• One linked-list of used partitions and holes
  ordered by the starting address
• Advantages
• Easy to merge partition with holes when a process
  releases its partition
• Easy to see if neighboring partition is a hole

17
Linked-list of Free/Used Partitions

• 2 separate linked-list (1) Partitions in use by
  a process, (2) Partitions of unused memory
  (holes)
• Advantage easy to find free partition to
  allocate to a process
• Disadvantage need to move partitions between
  the two lists when allocating/de-allocating
  memory space. This can be inefficient
• Is compaction easy with either of these
  implementations?

18
Methods of Allocating Free Hole to a New Process

• First fit find the 1st hole that has enough
  space
• Next fit dont start from beginning of
  linked-list when searching for 1st fit
• Best fit find smallest free space that will fit
  process
• Slow and results in many tiny, useless holes
  because exact fit is rare
• Worst fit find largest hole that will fit
  process
• Quick fit separate lists of common partition
  sizes are maintained and process is allocated a
  partition depending on which common size is
  closest and fits

19
Methods of Allocating Free Hole to a New Process

• First fit and quick fit are most practical
• If you have common fixed-sized blocks, use quick
  fit or bitmap (if blocks are a single size)
• Otherwise, use first fit
• Scan for free partition is fast, so fast
  allocation

20
Buddy System (used in Linux)

• Memory is iteratively divided
• Requests for memory are rounded up to power of 2
• When memory is released, free partitions are
  merged only if they are buddies
• Easy access to blocks of power-of-2 sizes
• Buddy system results in lots of internal
  fragmentation
• Exp. Request of size 65 will be given a block of
  size 128
• Basically, same internal fragmentation problem as
  seen with fixed-size partitions
• Linuxs solution
• Split blocks (chunks) up into smaller units
  (slabs) and have second memory allocation for the
  slabs
• Smaller units are managed separately from the
  large blocks

21
Variable Partitions

• These methods (bitmap, linked-lists, buddy
  system) no longer used for OS memory management
• These methods are now used in
• Disk swap space management
• Memory storage allocators (e.g., malloc( ))
• Dynamic allocation requires additional space to
  be allocated and is implemented using a heap
  space or allocating a hole with extra space
• Now, memory management is based on pages