Paging Design and Implementation Issues

Local v. Global
1. Global: The replacement algorithm considers all pages in memory.
2. Local: Replacement only considers pages owned by the faulting process.
3. With global, processes which need more pages naturally obtain them. Local requires a policy to modify the number of pages a process has.
4. Measuring the Page Fault Frequency (PFF) for each process can reveal which is suffering from its allocation size.
Load Control
1. Measure the overall PFF to see if the system is overloaded.
2. May want to swap a process out to reduce load on the VM system.
3. The process with the largest PFF is the obvious choice, but need to consider priorities, and keep enough processes running to keep the CPU busy.
Page Size
1. Basic page size is determined by hardware.
2. An OS can allocate pages in (small) groups, simulating larger pages for some purposes.
3. Most common size is 4K; systems have used 512 bytes to 64K.
4. Advantages of larger pages.
  1. Smaller page table, and fewer TLB entries needed.
  2. For page I/O, less time per byte moved. (I/O operations have a fixed time plus a variable time.)
5. Advantages of smaller pages.
  1. Reduced internal fragmentation in the last page.
  2. For page I/O, less time per page.
  3. When a reference brings a page into memory, less chance some of its contents is unrelated and not actually needed.
6. Derive a page size to minimize space overhead.
  1. Parameters:
    s: The average process size in bytes.
    p: The page size in bytes.
    e: Size of a page table entry in bytes.
  2. Each process needs s/p pages, using se/p bytes of page table entry space.
  3. The unused space (waste) in the last page will average p/2.
  4. overhead=se/p+p/2
  5. First derivative wrt p is −se/p2+1/2
  6. Set to zero, and we get √2se
  7. For s=1MB and e=8bytes, optimum page size is 4KB.
Starting a Program
1. When a program is run, it isn't loaded into memory.
2. A page table is created, with all entries invalid.
3. Execution begins and needed pages are brought in on demand.
4. Only the parts of the program actually run are ever loaded into memory.
Shared Pages
1. Each process has its own page table. The same page may be entered into more than one PT to allow sharing.
2. Creates extra record-keeping so shared pages aren't immediately removed when one process exits.
3. Explicit sharing for communication.
  1. Two processes may request a region of memory be mapped into both their page tables.
  2. Allows process to share information as threads do.
  3. Also creates the same sort of synchronization problems that shared data structures present.
4. Sharing can be created by the OS, invisible to the process, to reduce real memory use.
  1. Sharing read-only areas.
    1. A read-only region can be mapped into multiple page tables. None of the processes can detect the sharing.
    2. Particularly useful for code, since it is always read-only.
    3. When multiple processes run the same program, avoids loading into memory multiple times.
  2. Sharing read-write areas.
    1. If two processes simply share a writable area, the processes can easily detect that fact.
    2. To give each process the appearance of having its own copy, a process called copy-on-write is used.
      1. Pages are referenced by multiple page tables.
      2. All shared pages are marked read-only, even though the data is intended to be writable.
      3. When a write causes a fault, the O/S makes a copy of the page, and updates the PT of the faulting process to refer to the copy.
      4. The modified PTE is marked writable. (If the original page is no longer shared, its PTE can be marked writable also.)
      5. The program resumes with a private, writable copy of the page.
      6. None of the processes can detect what just happened.
    3. Only pages actually modified are copied.
    4. The Linux fork operation makes a COW copy of the calling process.
Shared Libraries
1. Modern systems do not actually add all libraries to a compiled executable.
2. The first call loads the library at run time.
3. The first process to load the library just maps it into the page table.
4. Additional users of the library share the pages, which are read-only.
Mapped Files
1. A file can be mapped into memory using paging.
2. Make page table entries that are invalid, but the disk image of each page is the corresponding portion of the file.
3. Can effectively perform I/O by memory reference.
Cleaning Policy
1. Instead of running the replacement algorithm when a fault occurs, most OS's keep a pool of available pages.
2. A paging daemon runs periodically and checks if there are enough pages in the pool. If not, it runs the replacement alg. and to add more.
3. When a page enters the available pool, it is written back if modified, but its contents remain in memory. If that page is needed again before it is actually replaced, it just be reclaimed from the pool without any I/O cost.
User Interface. Primarily, VM operation is transparent to the programmer. But there may be some operations:
1. Ask for a shared memory region. Allows fast communication.
2. Ask to memory-map a file.
3. Configure a distributed shared memory.
  1. Pages on different system can map to the same data.
  2. Fault handling requires a network operation.
OS Involvement: What the OS has to take care of to make VM work.
1. On process creation, set up paging.
  1. Allocate space for page table. Initial size usually based on size of the executable program.
  2. Swap area on disk must be set up so data can be accessed on a fault.
    More on this later.
  3. Information about the page table and swap area are recorded in the process table entry.
2. When a process changes state to running.
  1. Reset the MMU to clear out information from the previous virtual space. The TLB will be flushed.
  2. Make the new page table current by placing a pointer in some particular register, or possibly copying the whole table.
    On a Pentium, the page table address goes in a register is called cr3
  3. Possibly bring in some pages to prevent later faults.
3. When a fault occurs.
  1. Compute which page is needed and find it on disk.
  2. Find a frame, evicting a current one if needed.
  3. Move the needed page into the frame.
  4. Restart the instruction.
4. When a process exits, clean up.
  1. Free the page table space, and mark its real pages available.
    Modified pages backed by a file may need to be written to disk.
  2. But only for the pages no other process is using.
5. Page fault detail
  1. A trap saves the PC, and usually some other information, and transfers to the OS.
  2. An assembly-language trap handler saves the general registers, then calls a handler in the OS, usually written in C or a higher-level language.
  3. Determine the virtual address which caused the fault
    1. Convenient hardware has saved this in a register.
    2. Inconvenient hardware requires the OS to fetch the instruction pointed to by the saved PC, and figure out what it was doing.
  4. If the address is invalid, or the fault represents a protection violation, the program is generally terminated.
  5. Find a free frame. Either one is not in use, or from a page pool, or by running the replacement algorithm.
  6. If the chosen frame is modified, schedule a write and suspend the faulting process. The frame is marked busy so it isn't accidentally reused while waiting.
  7. When the page is clean (after write-back or immediately), find the needed page on disk and schedule a read to place it into memory. The process remains suspended until this finishes.
  8. When the disk interrupts to indicate read completion, the page table is updated and marked for normal use (remove busy mark).
  9. Depending on the architecture, the PC value saved at the fault may need to be adjust to point to the start of the faulting instruction. On some architectures, partial results may need to be reversed.
  10. Eventually, the faulting process is scheduled to run again. The assembly-level fault handler resumes. This reloads the state information (including the PC), returns to user space, and the program retries the instruction which faulted.
Instruction Backup
1. On some architectures leave a mess after a page fault.
2. The hardware may interpret the instruction in steps, and be part way through when the fault occurs.
3. An instruction may have multiple arguments in memory, any one of which could fault.
4. Some architectures auto-increment registers.
5. The OS will need to figure out which address faulted, which PC value is the start of the instruction, and reverse any auto-increments.
6. Hardware may give more or less help.
7. Newer architectures are simpler to deal with than this.
Locked Pages.
1. If an DMA operation is moving information to or from a some page, it must not be paged out.
2. The OS marks the page as locked so the replacement algorithm will ignore it.
Backing Store
1. Each page must have a backing location on disk.
2. A swap area
  1. A partition or file holding the on-disk copies.
  2. Disk locations computed by adding the virtual page number to the start of the disk area.
  3. Information may need to be copied to the swap area first.
3. Dynamic location.
  1. Place pages wherever there's room.
  2. Requires a directory in memory to map from virtual page number to disk location.
4. Memory-mapped files, including running executables and shared libraries, are treated as small swap areas.
Separation of Policy and Mechanism
1. Move replacement policy and backing store management to user space.
2. Faults reach the kernel, which requests pages from paging server.
3. User can control paging policy.
4. Different processes can use different approaches as desired.
5. Something your author likes, but not widely used.