From owner-freebsd-arch@freebsd.org Thu Nov 3 10:23:40 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 338FDC2D1BC for ; Thu, 3 Nov 2016 10:23:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3F19D104A for ; Thu, 3 Nov 2016 10:23:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26828 for ; Thu, 03 Nov 2016 12:17:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c2F5P-000N80-B9 for freebsd-arch@FreeBSD.ORG; Thu, 03 Nov 2016 12:17:31 +0200 Subject: Re: superio driver To: freebsd-arch@FreeBSD.org References: From: Andriy Gapon Message-ID: <0d588744-c83f-1f04-3c79-89cba63949a3@FreeBSD.org> Date: Thu, 3 Nov 2016 12:16:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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: Thu, 03 Nov 2016 10:23:40 -0000 On 17/10/2016 11:19, Andriy Gapon wrote: > > I would like to add a driver for Super I/O chips: > https://reviews.freebsd.org/D8175 > In the review request you can find my rationale and description for the driver > as well as some question about its design. > At this point I am looking mostly for some help with the design, but any reviews > of the current code are also appreciated. Still looking for comments and suggestions. Thanks! -- Andriy Gapon 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. From owner-freebsd-arch@freebsd.org Thu Nov 3 22:30:17 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 627B0C2D223 for ; Thu, 3 Nov 2016 22:30:17 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 25C501729; Thu, 3 Nov 2016 22:30:17 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: by mail-vk0-x22f.google.com with SMTP id p9so52625848vkd.3; Thu, 03 Nov 2016 15:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jHRXpqUkKlTiHcXpg6AxEVh5saKLnPU4LzjlEsD7Ccc=; b=Il8kF/ZqKty6gBsfZohv4u3WUYfEbD+iLRw2g+Gs43QyTKklQVXlu2JtYddlrrcBts uOk2LlYgPiflw51LZ6zhusRAUi+/NHvOT33SNvyBtmyTVWDtbIpJP0VGnJKekPlTTEZF SwJzjpqHS5JosJjT/nLQitr8GNsf1TP8P4xQds8ghvdRTYgSEJYZVOxiMAzAe+/2tT5G /g42sEaFcdF4bkEme8EfwQuzAcnfI+xGhAInuZ/z7RyynzRB9mmadrpjtShDVmD6swyy j+g2QsemIOcztEMwe/GMZUsz/r3VnIuxe/KPIFPK1aXcUnjGxa0x+HPnUjcuOMPwoA1G gzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jHRXpqUkKlTiHcXpg6AxEVh5saKLnPU4LzjlEsD7Ccc=; b=aj+H8N2VajtYO5QkVxXhPFEacHROUbHJ5QCgVxTzRp0Vqw0PoQalWApRLWo6lxb1Mt bn4RDnsG/gL+Y/4J/kBIBxCyPw+vSuR4RwBzgywM1pCkB89PClazwQ8mLRES3GSF/DDm xuSg0vm74gnyRTCe38of3BtMDgyL17n0odOH9AH/mRP1grmGxHx0pJCl9Xe51lKrvRdE m8pkO5g7hbwzQBCH6Pi9eD/MyUp4MtOsipn6OODws2GHmMdYP1KSowIY9ZQYTox/BvbR O2fqF2kN4S478i1VdFJbyLxo/kmhWhyiz6lAQA7gzahzZghHgCBCYbxakOjT7PcsgP6V Gohg== X-Gm-Message-State: ABUngvdWSoKoPyzqxM6KukRic01EqsJmDfNAJH4TWRkpsS8M2MvFXgOTm42ino10V0WdvURYVunHtoiFBEGvmA== X-Received: by 10.31.229.133 with SMTP id c127mr9504930vkh.153.1478212215992; Thu, 03 Nov 2016 15:30:15 -0700 (PDT) MIME-Version: 1.0 Sender: mureninc@gmail.com Received: by 10.176.1.147 with HTTP; Thu, 3 Nov 2016 15:30:15 -0700 (PDT) In-Reply-To: <0d588744-c83f-1f04-3c79-89cba63949a3@FreeBSD.org> References: <0d588744-c83f-1f04-3c79-89cba63949a3@FreeBSD.org> From: "Constantine A. Murenin" Date: Thu, 3 Nov 2016 17:30:15 -0500 X-Google-Sender-Auth: 2PIcmBCEiHj5jpRI8-K8fUno-dc Message-ID: Subject: Re: superio driver To: Andriy Gapon Cc: "freebsd-arch@freebsd.org" , "Constantine A. Murenin" Content-Type: text/plain; charset=UTF-8 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 22:30:17 -0000 On 3 November 2016 at 05:16, Andriy Gapon wrote: > On 17/10/2016 11:19, Andriy Gapon wrote: >> >> I would like to add a driver for Super I/O chips: >> https://reviews.freebsd.org/D8175 >> In the review request you can find my rationale and description for the driver >> as well as some question about its design. >> At this point I am looking mostly for some help with the design, but any reviews >> of the current code are also appreciated. > > Still looking for comments and suggestions. > Thanks! I think it's an interesting idea; I've had it a few years ago in the context of OpenBSD, but didn't pursue it further due to a lack of much uniformity around the Super I/O chips from different vendors. LPC Super I/O chips from Winbond/Nuvoton and ITE do use a separate ISA port for its Hardware Monitor functionality (often 0x290/8), and the exact port number itself is still best be discovered through the Super I/O driver (0x2e/2). On the other hand, the watchdog timer is nonetheless usually implemented within the confines of the main Super I/O logic itself (e.g., 0x2e/2). http://mail-index.netbsd.org/tech-kern/2010/02/17/msg007343.html http://mdoc.su/f110/wbwd.4 In the case of Winbond, as per above, it did result in two drivers being there in {Net,Open,DragonFly}BSD, one for the Super I/O that does the discovery (and which might potentially have support for the watchdog functionality), and another for the Hardware Monitor (the lm-compatible one, which can also attach directly on I2C in {Net,Open}BSD): http://bxr.su/DragonFly/sys/dev/powermng/wbsio/wbsio.c http://mdoc.su/n,o,d/wbsio.4 http://mdoc.su/n,o,d/lm.4 However, in the case of http://mdoc.su/o/viasio.4 and http://mdoc.su/n/itesio.4, the logic of Super I/O and Hardware Monitor may be stuffed together into a single driver, even though both functions are still performed at separate IO ports (look for the multiple bus_space_map(9) calls, in fact, viasio(4) has separate ports not only for the Hardware Monitor function, but for the Watchdog Timer as well, something which is unique to it and is not shared by ITE and Winbond/Nuvoton chips; nonetheless, all of these ports are claimed by a single driver): http://bxr.su/OpenBSD/sys/dev/isa/viasio.c#viasio_hm_init http://bxr.su/NetBSD/sys/dev/isa/itesio_isa.c#itesio_isa_attach If support for all of these Super IO chips would be implemented in a single driver, then FreeBSD might as well end up with its own version of what the I2C bus scan is on OpenBSD: http://bxr.su/OpenBSD/sys/dev/i2c/i2c_scan.c#iic_probe_sensor Which is not necessarily a bad thing, and, in fact, provides an I2C discovery interface which is very similar to what the situation is on the more well designed platforms compared to x86, e.g., those that have a smart property-based discovery mechanism via Open Firmware. However, realistically, I am not sure what will we gain in this case of probing for all of these Super I/O chips from a single bus driver; in fact, as you've already noticed yourself, even the probing mechanisms are already different between ITE and Winbond/Nuvoton, so, what exactly do we gain by having it all together in a new bus? Cheers, Constantine.SU. 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 From owner-freebsd-arch@freebsd.org Sat Nov 5 17:41:55 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 E94EFBEDE6E for ; Sat, 5 Nov 2016 17:41:55 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 C0539617 for ; Sat, 5 Nov 2016 17:41:55 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x232.google.com with SMTP id n85so69225002pfi.1 for ; Sat, 05 Nov 2016 10:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TDBtZ9Wn0HgT7UitVrVV/Vb67Ee0pQG7eYBjN4oKPn8=; b=mSsKaKo7G6gxkHgRu2J9f6JJvAD+9n1a6OEbXydv9j3IUAt5HOPyvBFwKSWsqV2Il9 yUObWMRZDoVSJNwgo38JRU5PM7YlMTULCa2XPtgpfxbR1SWUxFM9F7UDSrfrl0UbUgEs 2nZX58gvXwS0V4l+vyKI2ofnk2+Sy0e2+9OBcxGcU8CNuKBljID4Arkl+ndEU9D13LtU N6JrbBZOiIx88KLHr4ncxIWEdxidkXLoFAW11BHBlMJq82pa0GswepQEehnTd1IYHuw3 CCN6IBlPyjje66Pxley/DD94p3YKa7Xw2ID+aq7Qn0WoOpiyc+4EVrAT4mS/TNczLjMN 8fYA== 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:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=TDBtZ9Wn0HgT7UitVrVV/Vb67Ee0pQG7eYBjN4oKPn8=; b=mRHxbGky2uDqZPHCnmZklUnOV353aS7OvVsYKL7QThGnDudYLgwiBGTtIMangwLzEe 3oyxjtCmg5AUEE/Qd3b9+YhJcNGFjJH+r7XiRHaW7p0dd8WNlhsK9NxHu3BdZpFVn2vD dGuaCmsazfpIa32FCl3XNhQgKjyL4t5oStzAVIlT6ke+aS4iEpIwVUoH+YxUJxvOJ+hs gDgH/bvRVTQ9fhFZz4/76JrnesARxCNtxT0BTg+YMpRpMFvDeUYxApZC5TX9kwLyI2R+ Qwaeur5nSGFkJUkZNNDKsukdmZRC2BEtriJ51WVjbsZeL59RYCq2su/dFVj/WQu61xqi ay2Q== X-Gm-Message-State: ABUngveOGML51rbeRGVNk7Fv6Dtz3rx3uHBMF7JZWylBi3Pn6ftPSwzH8ZdvZK/WUEbisg== X-Received: by 10.99.135.200 with SMTP id i191mr31662603pge.18.1478367714859; Sat, 05 Nov 2016 10:41:54 -0700 (PDT) Received: from raichu ([2604:4080:1102:0:ca60:ff:fe9d:3963]) by smtp.gmail.com with ESMTPSA id d15sm10680969pfl.46.2016.11.05.10.41.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Nov 2016 10:41:54 -0700 (PDT) Sender: Mark Johnston Date: Sat, 5 Nov 2016 10:41:48 -0700 From: Mark Johnston To: Gary Jennejohn Cc: freebsd-arch@freebsd.org Subject: Re: PQ_LAUNDRY Message-ID: <20161105174148.GA75901@raichu> References: <20161103182916.GA31178@wkstn-mjohnston.west.isilon.com> <20161105103128.78197d36@ernst.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161105103128.78197d36@ernst.home> User-Agent: Mutt/1.7.0 (2016-08-17) 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 17:41:56 -0000 On Sat, Nov 05, 2016 at 10:31:28AM +0100, Gary Jennejohn wrote: > On Thu, 3 Nov 2016 11:29:16 -0700 > Mark Johnston wrote: > > 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. Are you computing the amount swapped out as the amount of memory swapped out minus the amount of swapins? Or is 125MB the amount of swap used after the test? Output from "sysctl vm.stats" taken before and after any test on both HEAD on PQ_LAUNDRY would be most useful. > > 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 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"