Date: Thu, 3 Nov 2016 11:29:16 -0700 From: Mark Johnston <markj@FreeBSD.org> To: freebsd-arch@freebsd.org Subject: PQ_LAUNDRY Message-ID: <20161103182916.GA31178@wkstn-mjohnston.west.isilon.com>
next in thread | raw e-mail | index | archive | help
Hi, Alan and I have been working on a branch at user/alc/PQ_LAUNDRY in svn. It reworks the mechanism and policy used for dirty page laundering. Currently, the inactive queue is used to store pages eligible for reclamation by the pagedaemon. It contains both clean and dirty pages. Dirty pages must be laundered before they may be reclaimed; that is, they must either be written to swap, or to persistent storage (i.e., a filesystem). Because laundering a page is an expensive operation, the pagedaemon will perform at most a small number of launderings in a first-pass scan of the inactive queue. The PQ_LAUNDRY branch adds a new page queue, PQ_LAUNDRY, to store dirty pages that have passed once through the inactive queue. A dedicated thread is responsible for both deciding when to launder pages, and actually laundering them. The new policy uses the relative sizes of the inactive and laundry queues to determine whether to launder pages at a given point. This leads to more intelligent swapping behaviour in general, since the laundry thread will avoid swapping when the marginal benefit of doing so is low. Without a dedicated queue for dirty pages, the pagedaemon doesn't have the information to determine whether swapping provides any utility to the system. Thus, the current policy often results in small but steadily increasing amounts of swap usage when the system is under memory pressure, even when the inactive queue consists mostly of clean pages. PQ_LAUNDRY addresses this, and incidentally also helps pave the way for some future VM improvements by removing the last source of object-cached clean pages (PG_CACHE pages). Some more details and the diff for PQ_LAUNDRY can be viewed here: https://reviews.freebsd.org/D8302 We would like to commit it next week. Any additional comments, review, or testing would be welcome.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161103182916.GA31178>