NOTE: These notes are by Allan Gottlieb, and are reproduced here, with superficial modifications, with his permission. "I" in this text generally refers to Prof. Gottlieb, except in regards to administrative matters.

================ Start Lecture #11 (Mar. 24) ================

Page replacement with multi-level page tables

A level-2 page in a multi-level page table is not replaced until all the pages it points to are out of memory.

Paging with multiple process

Each process needs a separate page table. Conceptually part of the process table entry. Page table for current process in specific array in kernel space. Saved and reloaded at context switch.

4.6: Design issues for (demand) Paging Systems

4.6.1: Local vs Global Allocation Policies

A local PRA is one is which a victim page is chosen among the pages of the same process that requires a new page. That is the number of pages for each process is fixed. So LRU means the page least recently used by this process.

If we apply global LRU indiscriminately with some sort of RR processor scheduling policy, and memory is somewhat over-committed, then by the time we get around to a process, all the others have run and have probably paged out this process.

If this happens each process will need to page fault at a high rate; this is called thrashing.

It is therefore important to get a good idea of how many pages a process needs, so that we can balance the local and global desires. The working set W(t,ω) is good for this.

An approximation to the working set policy that is useful for determining how many frames a process needs (but not which pages) is the Page Fault Frequency (PFF) algorithm.

As mentioned above a question arises what to do if the sum of the working set sizes exceeds the amount of physical memory available. This question is similar to the final point about PFF and brings us to consider controlling the load (or memory pressure).

4.6.3: Page size

4.7: Implementation Issues

4.7.1: Operating System Involvement with Paging

4.7.2: Page Fault Handling

What happens when a process, say process A, gets a page fault?
  1. The hardware detects the fault and traps to the kernel (switches to supervisor mode and saves state).

  2. Some assembly language code save more state, establishes the C-language (or another programming language) environment, and ``calls'' the OS.

  3. The OS determines that a page fault occurred and which page was referenced.

  4. If the virtual address is invalid, process A is killed. If the virtual address is valid, the OS must find a free frame. If there is no free frames, the OS selects a victim frame. Call the process owning the victim frame, process B. (If the page replacement algorithm is local process B is process A.)

  5. If the victim frame is dirty, the OS schedules an I/O write to copy the frame to disk. Thus, if the victim frame is dirty, process B is blocked (it might already be blocked for some other reason). Process A is also blocked since it needs to wait for this frame to be free. The process scheduler is invoked to perform a context switch.

  6. Now the O/S has a clean frame (this may be much later in wall clock time if a victim frame had to be written). The O/S schedules an I/O to read the desired page into this clean frame. Process A is blocked (perhaps for the second time) and hence the process scheduler is invoked to perform a context switch.

  7. A Disk interrupt occurs when the I/O completes (trap / asm / OS determines I/O done). The PTE is updated.

  8. The O/S may need to fix up process A (e.g. reset the program counter to re-execute the instruction that caused the page fault).

  9. Process A is placed on the ready list and eventually is chosen by the scheduler to run. Recall that process A is executing O/S code.

  10. The OS returns to the first assembly language routine.

  11. The assembly language routine restores registers, etc. and ``returns'' to user mode.

Process A is unaware that all this happened.

4.7.3: Instruction Backup

A cute horror story. The 68000 was so bad in this regard that early demand paging systems for the 68000, used two processors one running one instruction behind. If the first got a page fault, there wasn't always enough information to figure out what to do so the system switched to the second processor after it did the page fault. Don't worry about instruction backup. Very machine dependent and modern implementations tend to get it right. The next generation machine, 68010, provided extra information on the stack so the horrible 2-processor kludge was no longer necessary.

4.7.4: Locking (Pinning) Pages in Memory

We discussed pinning jobs already. The same (mostly I/O) considerations apply to pages.

4.7.5: Backing Store

The issue is where on disk do we put pages.

4.2: Swapping

Medium-term scheduling:

Suspending: Taking an active process entirely out of memory and saving its state on disk.

Resuming: Loading a suspended process from disk to memory.

A suspended process may be blocked (waiting for some other event to complete) or it may be suspended and ready (i.e. ready to run as soon as it is swapped in.)

In an OS that uses variable-length partitions, swapping can be done when some waiting process can't fit in memory; especially when the memory requirements of all active process is larger than total memory. In an OS that uses paging, swapping can be done when the working set sizes of the active processes are together larger than physical memory, so that keeping all processes active leads to thrashing.

Unlike previous similar issues, such as short-term scheduling and page replacement, I am not going to give a list of a half-dozen simple swapping algorithms. Swapping is more complicated and doesn't lend itself to simple algorithms. (Also, it is done comparatively infrequently, so one can afford to spend time on a complicated algorithm.) Rather, there are a number of considerations that must be combined.

First, note that there are two decisions to be made: which, if any, jobs to swap in and which, if any, to swap out. With variable length partitioning, these are always combined. The only reason to swap one job out is to swap another in. You can only swap a job in if either an active job terminates or if you swap some other job out.

With a paging system, it may become desirable to swap one job out and not bring any in, if the working sets of the active jobs grow; or it may become feasible to swap a job in without any other job terminating or being suspended, if the working sets shrink.

Criteria for choosing jobs to swap in / out

The bottom line is that if you have to do a lot of swapping, you're in trouble.