From owner-freebsd-current@freebsd.org Mon Mar 14 14:20:06 2016 Return-Path: Delivered-To: freebsd-current@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 04E4EAD0CF9 for ; Mon, 14 Mar 2016 14:20:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DEC8B79 for ; Mon, 14 Mar 2016 14:20:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id DA849AD0CF8; Mon, 14 Mar 2016 14:20:05 +0000 (UTC) Delivered-To: current@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 C0452AD0CF7 for ; Mon, 14 Mar 2016 14:20:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3E9177 for ; Mon, 14 Mar 2016 14:20:05 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 18d96da8-e9f0-11e5-8de6-958346fd02ba X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 14 Mar 2016 14:21:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2EEJvOU020732; Mon, 14 Mar 2016 08:19:57 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1457965197.9986.12.camel@freebsd.org> Subject: Re: how to recycle Inact memory more aggressively? From: Ian Lepore To: Adrian Chadd , Mark Johnston Cc: Gary Jennejohn , "current@freebsd.org" Date: Mon, 14 Mar 2016 08:19:57 -0600 In-Reply-To: References: <20160312093835.727d7197@ernst.home> <20160314013319.GA68039@wkstn-mjohnston.west.isilon.com> <20160314015104.GB68039@wkstn-mjohnston.west.isilon.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 14:20:06 -0000 On Sun, 2016-03-13 at 19:08 -0700, Adrian Chadd wrote: > On 13 March 2016 at 18:51, Mark Johnston wrote: > > On Sun, Mar 13, 2016 at 06:33:46PM -0700, Adrian Chadd wrote: > > > Hi, > > > > > > I can reproduce this by doing a mkimage on a large destination > > > file > > > image. it looks like it causes all the desktop processes to get > > > paged > > > out whilst it's doing so, and then the whole UI freezes until it > > > catches up. > > > > mkimg(1) maps the destination file with MAP_NOSYNC, so if it's > > larger > > than RAM, I think it'll basically force the pagedaemon to write out > > the > > image as it tries to reclaim pages from the inactive queue. This > > can > > cause stalls if the pagedaemon blocks waiting for some I/O to > > complete. > > The user/alc/PQ_LAUNDRY branch helps alleviate this problem by > > using a > > different thread to launder dirty pages. I use mkimg on various > > desktop > > machines to build bhyve images and have noticed the problem you're > > describing; PQ_LAUNDRY helps quite a bit in that case. But I don't > > know > > why this would be a new problem. > > > > That's why I'm confused. I just know that it didn't used to cause the > whole UI to hang due to paging. > I've been noticing this too. This machine runs 10-stable and this use of the swap began happening recently when I updated from 10-stable around the 10.2 release time to 10-stable right about when the 10.3 code freeze began. In my case I have no zfs anything here. I noticed the problem bigtime yesterday when rsync was syncing a ufs filesystem of about 500GB from one disk to another (probably 70-80 GB actually needed copying). My desktop apps were noticibly unresponsive when I activated a window that had been idle for a while (like it would take a couple seconds for the app to begin responding). I could see lots of swap In happening in top during this unresponsiveness, and noticible amounts of Out activity when nothing was happening except the rsync. This is amd64, 12GB ram, 16GB swap, a tmpfs had about 400MB in it at the time. Prior to the update around the 10.3 freeze, this machine would never touch the swap no matter what workload I threw at it (this rsync stuff happens every day, it's the usual workload). -- Ian