UNIX System Administration Handbook - Evi Nemeth [450]
The kernel maintains a free list of pages that are eligible to be paged out. When memory is low, pages are placed on the free list seemingly at random. (Actually, there is a defined order, so the “clock” hand points to every page equally often.) As a page is placed on the free list, its address mapping is unwired from the memory controller so that the next time a process attempts to access it, a fault is generated.
If a “freed” page is referenced before being paged out (an event called a soft fault), the kernel takes it off the free list and rewires its address mapping. The page is then safe until the next pass of the page-freeing clock. On average, infrequently referenced pages don’t get rescued; their contents are eventually written out to disk and they are then recycled.3
Demand for memory varies, so the kernel can run the page-freeing clock at different speeds. If there is plenty of memory, the clock does not run at all, thus sparing the system the overhead of processing soft page faults. When the demand for memory is extreme, the clock runs at high speed and pages must be rescued in a shorter amount of time to avoid being paged out.
The virtual memory (VM) system depends on the lag between the time when a page is placed on the free list and the time when it’s actually paged out to sort active pages from inactive pages. Therefore, it has to predict future paging activity in order to select an appropriate speed for the paging clock. If the clock runs too slowly, there might not be enough pages on the free list to satisfy demand. If too fast, the kernel spends excessive time processing soft page faults.
Since the paging algorithm is predictive, there is not necessarily a one-to-one correspondence between page-out events and page allocations by running processes. The goal of the system is to keep enough free memory handy that processes don’t have to actually wait for a page-out each time they make a new allocation.
Swapping is handled somewhat differently from paging. It’s also done predictively, but on the basis of accurate per-process records rather than statistical estimates. If
memory is scarce and a process is known to have been idle for a long time (tens of seconds), it makes sense to write out all its pages at once rather than waiting for the paging algorithm to collect them.
It is a very bad sign if the kernel forcibly swaps out runnable processes. This is called thrashing or desperation swapping, and it indicates an extreme memory shortage. In this situation, it’s likely that a substantial portion of the system’s resources are being devoted to memory housekeeping rather than to useful work.
A similar VM pathology can occur when two large processes compete for the CPU. When the first process gets to run, it brings in a group of its own pages, forcing out some of the second process’s pages. Then the second process runs and reinstates its own pages at the expense of the first process. Neither process gets much work done.
Even processes running at a low CPU priority can be sneaky page thieves. For example, suppose you’re running a simulation at very low priority (high nice value) on your workstation, while at the same time reading mail in a terminal window. As you pause to read a message, your CPU use falls to zero and the simulation is allowed to run. It brings in all of its pages, forcing out your shell, your window server, your mail reader, and your terminal emulator. When you type n to go on to the next message, there is a delay as a large chunk of the system’s memory is turned over. In real life, a high nice value is no guarantee