From owner-freebsd-arch@freebsd.org Thu Nov 3 18:23:49 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91FD0C2E06A for ; Thu, 3 Nov 2016 18:23:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63E8314AF for ; Thu, 3 Nov 2016 18:23:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x229.google.com with SMTP id n85so35755072pfi.1 for ; Thu, 03 Nov 2016 11:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=w0qe7oqnOQnEx5Hp+by7veV/s8P3iNaIz0j0Jv5/wH0=; b=FhD+wLJZIELDbBHFVNPaLBMtunCV+3I8ENbziita/V7VwvBZE6AIZQHMEiDYdiQdyc DG7nbqqOL4FSwxB0J/rKCFjnyWgvgumKuN5HFD29632bw7nrVQG2uXLByhkNuGf30c7Y gRk6bO2lpVnKgwCrRvHDnH7593i63MtpFsxR4Bkr9IsJ+6uWVVL6oBK7n/iAJ/ZiwIDY hrBJ0rQxlznsh3RWO6ivVOwt/2JXBG/gmIJdkzfNWH0qFiEB8hCviv9L5V+yTPqXZNrD 5wmxEflyHZL6AwtBW50pXWZGLoG0TCCk/dBRVLLWquDUYTcqPl6dACsciYJw0izMwO0F VPgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=w0qe7oqnOQnEx5Hp+by7veV/s8P3iNaIz0j0Jv5/wH0=; b=VfF76yY4/WuIbbl4iKMbeNYCmSn0FnYtY0EEhQe7dc+6Y2ALujgX3gBTru2L1uHDxL 0q42CojpVrx1bVSpBvMYYzJMHo++iJXSR2C9C725XiNtFAc5VxuLfGqGt/GnUnfV5g3J PF4YdYeng6el4aLJJR/KaBz5brrw9E93gK5xiRI8HZBROTO6gMDS2p0BA+NehhwM0LU2 DfoOcaGfyP93XbTHqbdp9Sdxta4fYyh1nF05t0cj6QTSYrG28F0o//Re5uA1azyAVBLr UnkNNyqN1RQc8nIa/bqhAbjKST/ruNGBPZugwqTOB1mygCNbxUvVroDuPR8hdL51GLXN mnUg== X-Gm-Message-State: ABUngvcwRCFw8a2L4V7/XJ4erzAioPCXgl7YN2VeFTCCWR6fLtfVmaXmKMwfE+/jiuZl7g== X-Received: by 10.98.100.215 with SMTP id y206mr19119797pfb.49.1478197428702; Thu, 03 Nov 2016 11:23:48 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id d26sm14370555pfb.37.2016.11.03.11.23.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 11:23:48 -0700 (PDT) Sender: Mark Johnston Date: Thu, 3 Nov 2016 11:29:16 -0700 From: Mark Johnston To: freebsd-arch@freebsd.org Subject: PQ_LAUNDRY Message-ID: <20161103182916.GA31178@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:23:49 -0000 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.