Chapter 9 -- Virtual Memory

  1. Basic Idea
    1. Purpose: To give the illusion that there is more memory than you have.
    2. Purpose: To speed the loading of programs by not loading unnecessary code or just loading the startup code on startup.
    3. Observation: Most programs have code they need rarely, like error code.
    4. Observation: Most programs go thru phases, and you only need keep one phase in memory at a time (like overlays, but not quite as good.)
    5. Observation: Most programs delcare arrays bigger than needed. C and FORTRAN seem to make this a big habit.
    6. Observation: Most programs only work with a small subset of their data (Like an airport lookup or a BBall stats program).
  2. Implementation: Demand Paging
    1. Yes, their is a demand segmentation. Pretty much the same thing, except that segments have variable size and tend to be bigger.
    2. Hardware:
      1. Page table needs a valid-invalid bit, and really should have a r/w bit and a referenced bit.
      2. Need CPU to generate a page-fault when tries to access an invalid page.
      3. Place to store memory (like a disk).
      4. Can restart all instructions.
        1. Consider string copy instructions for overlapping strings.
        2. Consider REP-COUNT instructions of i386.
    3. What to do when a page-fault occures:
        4. If (reference is not valid)
    error the process
Get a free page
Read the page off the disk (scheduler does stuff here)
change the page table to reflect the new page
restart the faulting instruction
    4. Performance:
      1. A single instruction can generate MANY page faults.
      2. Luckily, almost all instructions generate NO page faults.
      3. For computation in the book
        1. effective-access-time = (1-p) * memory + p * disk
    5. Hard problem: Which page to swap out when you need to swap out.
      1. Kill process instead.
      2. Use FIFO
      3. Use LRU
      4. Use some sort of frequency.
  3. Program Structure
    1. Good for V.M. subsystems
      1. Accessing arrays in linear order
      2. Not using more array than needed
      3. Special multidimensioned arrays
        1. Vary the rightmost index most often
        2. Make the dimentioned size of the leftmost indexes be minimal
      4. Stacks have great locality
      5. Tree structures that have large branching factor
      6. Putting all error handling code in in file
      7. Putting related function in one file
      8. Large sections of read only data
    2. Bad for locality (and therefore VM)
      1. Following pointers in general
      2. Tree structures with small branching factors
      3. Hash tables
      4. Large sections of written data or mixed data
  4. V.M. allocation and fairness
    1. Conflicting goals:
      1. Want to allocate pages for maximum global performance
      2. Don't want other greedy people to hurt me
    2. Fixed allocation per process, local replacement policy
      1. Each process is given a quantity of pages on startup, never to change
      2. When a new page need to be brought in for this process, the same process loses a different page
      3. Easy to administer
        1. Have humans set quantity
        2. Have program tell O.S. on start up.
      4. Can result in very poor global performance due to a few poor processes
      5. Can waste memory
    3. Variable allocation per process, global replacement policy
      1. Choose a victum page based on some global quality, such as oldest unused page in RAM.
      2. Processes can gain or loose memory
      3. Provides global best performance
      4. Others can effect YOU adversly
    4. Variable allocation per process, local replacement policy
      1. Each process has a fixed allocation of pages.
      2. On each page fault, faulting process donates a page
      3. Occasionally, allocations are reviewed and changed
        1. by humans
        2. more frequently, by automatic review of things like fault frequency
      4. Others can only somewhat hurt YOU, global performance O.K.
      5. Really, this is a compromise
  5. Swapping
    1. Swapping is moving out to secondary storage ALL of a process.
    2. Proccesses cannot run when the are swapped.
    3. Swapping should occur when the RAM is overcommitted.
      1. Can stop system from seeming locked up (always soem room for root to log in)
      2. Can increase global performance
    4. How to swap
      1. If load is to high
        1. Pick a non-swapped process
          1. Choose by UID (not root)
          2. By I/O (don't pick interactive processes)
          3. By memory allocation (pick large processes)
          4. By prioity (pick low)
          5. By page fault freqency (pick high)
          6. Most recently started process (likely to not be in RAM yet).
        2. Stop scheduling it
        3. Shove it out to disk
      2.  If load is too low
        1. Pick a swapped process
        2. Bring it in from disk
        3. begin scheduling it (put on ready queue).
  6. Overcommitment of V.M. resources
    1. Suppose you have 40M swapspace and 20M ram.
    2. Only promise 60M total virtual space
      1. Often must not accept requests when you really could
      2. Can always meet any promise made
    3. Promise the world
      1. Almost never get caught in lie
      2. Sometimes in trouble
        1. freeze process causing problem -- hope page frees up
          1. probably won't, probably deadlocked
        2. kill someone
          1. causes lost work, anonyed people