Add a basic laundering policy.
This policy stems from the notion that there are two reasons to launder
pages:
- Shortfall, in which the inactive and free queues are depleted, and the system must launder dirty pages in order to reclaim memory.
- Fairness: the system should periodically launder dirty pages to ensure that applications cannot excessively influence the system's memory reclaimation behaviour. Note that this does not imply that clear and dirty pages must be treated equally: page laundering is an expensive operation. However, the relative costs of reclaiming a clean vs. dirty page should be bounded in some well-defined way, and in particular, it should not be possible to force the system to reclaim only clean pages indefinitely. Under memory pressure the system should eventually launder some dirty pages, even when inactive clean pages are plentiful.
Thus, laundering targets are chosen based on the current state of the
paging queues. In shortfall, the laundry thread attempts to meet the
shortfall within 0.5s, the pagedaemon sleep period. Because it is the
sole source of clean pages, no attempts are made to limit the laundering
rate: the laundry thread goes all-out.
If the system is not in shortfall, the laundry thread may elect to
launder some dirty pages in an attempt to satisfy the fairness policy.
This is referred to as background laundering. Several conditions must be
met for background laundering to occur:
a) The laundry queue must contain a significant amount of the system's
inactive memory: if the number of dirty pages is miniscule, nothing is gained by laundering them. Moreover, write clustering works better if the number of dirty pages is allowed to grow to some threshold before any laundering is performed. The ratio of clean to dirty pages serves as a threshold here, controlled by bkgrd_launder_ratio. By default, dirty pages must constitute at least 1% of inactive memory for background laundering to occur.
b) The number of free pages must be low. If there is plentiful free
memory, there's no reason to launder pages. The number of free pages must be smaller than bkgrd_launder_thresh for background laundering to occur. By default, this is chosen to be the max of half the free target and 3/2s of the pagedaemon wakeup threshold. The idea is to start laundering before the pagedaemon wakes up.
c) The pagedaemon thread(s) must be active. If the number of free pages
is low but the system is not under memory pressure, we should not continue background laundering indefinitely. We use vm_cnt.v_pdwakeups as a proxy for pagedaemon activity: when a background laundering run begins, the pdwakeups value is recorded; a second run cannot begin until pdwakeups has been incremented at least once.
When the conditions for background laundering are met, the laundry
thread determines the target number of pages and begins laundering. It
attempts to meet the target within one second unless the corresponding
laundering rate would exceed bkgrd_launder_max (32MB/s by default). The
target is given by 0.5*l(L)*FT/l(I), where FT is the free page threshold
used by the pagedaemon. In particular, the number of pages laundered is
proportional to the ratio of dirty to clean inactive pages. When
performing background laundering, the pagedaemon counts reactivated
pages towards its target.
Reviewed by: alc