K 10
svn:author
V 5
markj
K 8
svn:date
V 27
2016-05-23T06:04:38.498309Z
K 7
svn:log
V 3442
Add a basic laundering policy.

This policy stems from the notion that there are two reasons to launder
pages:

1. Shortfall, in which the inactive and free queues are depleted, and
   the system must launder dirty pages in order to reclaim memory.

2. 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

END