From owner-freebsd-arch@freebsd.org Sat Nov 5 09:31:35 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 980A4C2DAA8 for ; Sat, 5 Nov 2016 09:31:35 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 3ACF2C4C for ; Sat, 5 Nov 2016 09:31:35 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id a197so93515070wmd.0 for ; Sat, 05 Nov 2016 02:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=XAbUIqVPi1uBEQRtp7Ywl99lNc/0csB/9tA5O6wGxnY=; b=Q74nPJLtEITClj5qa20zPsfhjPFrm2m3bFdw6n5Af3VfdeNmkkduus1H69AOLTQGHY kQPHE1GRKGmL0MhXlnAbbokZ5NNepKhSVS7qOBVMGXB2FQNhxVMsd2u4bsp6wQKfUISX bNejNu/BEgzDE8SPRJeEAaIDJNSFWsZsHDvSNGv2ITmJ+q/GB1Xa5fH93KkbC1LwvQ37 F6wKxlDHK/coIP00AGvvaxnSDGIJQM655YTvxBknCPST9br65UGhcOe4mLqODtxzM1Uw co65mzoBzkf3SaUqbO6rPnx8a2xXGlHZFW+nuaUrtVgIvH/i1U6zwEzuQFMbW8JBkiG1 KvdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=XAbUIqVPi1uBEQRtp7Ywl99lNc/0csB/9tA5O6wGxnY=; b=nKX36MqpKSDNDQg0RYW/RwmLqSe4yD3VQAP0emhrB5Dbil9UUHVpmkuQIHAJkAN8m+ FV1HuiD9fCTW9IHl4C0ciI79x3XA9naK1GkJPvvvrFNiJsGae3nbuB6f4A43m45oLAK/ gMLnwY27Nla9Oy03u72uLPG97AK3uNODbwiW9qm2Sz/IOFvZTAA1BH1OY6pJz2o5mvUi /JjKUK63j3GnkJ7f9Mx5i6PMeszdTafae47CGtol09CZj8tUASWcMEdbdizURixwu2Oi LS6fVqKT1eAYXbYTO3/ioyGmIERf2HYzkUYGECCJ2cUWr5DLYuTjBf5oExzh7THIFPkV y8Pw== X-Gm-Message-State: ABUngvfjw5Cf8/4qC23Gc0Sr3pTw/r0vJ6/TmX7Hufd5yNfmyl+b8uuHKiP5RzYuOVleEg== X-Received: by 10.194.142.116 with SMTP id rv20mr15106671wjb.184.1478338293370; Sat, 05 Nov 2016 02:31:33 -0700 (PDT) Received: from ernst.home (p4FCA605C.dip0.t-ipconnect.de. [79.202.96.92]) by smtp.gmail.com with ESMTPSA id j6sm6191306wjk.25.2016.11.05.02.31.29 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 05 Nov 2016 02:31:30 -0700 (PDT) Date: Sat, 5 Nov 2016 10:31:28 +0100 From: Gary Jennejohn To: freebsd-arch@freebsd.org Subject: Re: PQ_LAUNDRY Message-ID: <20161105103128.78197d36@ernst.home> In-Reply-To: <20161103182916.GA31178@wkstn-mjohnston.west.isilon.com> References: <20161103182916.GA31178@wkstn-mjohnston.west.isilon.com> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Sat, 05 Nov 2016 09:31:35 -0000 On Thu, 3 Nov 2016 11:29:16 -0700 Mark Johnston wrote: > 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. > In my use case, which is moving multi-gigabyte video files from one file system to another, this seems to swap more than the previous code did. Moving such large files with the previous code seemed to recycle Inact more quickly and IIRC only a few 10s of MB were swapped out. In my test this morning 125MB were swapped out and Inact was not recycled as quickly. The overall size of the files moved was about the same in the two tests. This code doesn't even come close to the behavior we had about 2 years ago. I could move 100s of GB and never see a single bye get swapped because Inact was very quickly recycled in multi-GB chunks, frequently the approx. 6GB of Inact would be recycled in a (to the human eye) single transfer to Free. In any case, the new code doesn't break anything. -- Gary Jennejohn