From owner-freebsd-current@freebsd.org Mon Mar 14 02:08:33 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 25262AD0AD9 for ; Mon, 14 Mar 2016 02:08:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) 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 0712C135F for ; Mon, 14 Mar 2016 02:08:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0256FAD0AD8; Mon, 14 Mar 2016 02:08:33 +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 01F6AAD0AD7 for ; Mon, 14 Mar 2016 02:08:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 C299F135D; Mon, 14 Mar 2016 02:08:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id z76so206749667iof.3; Sun, 13 Mar 2016 19:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nNWHkJY77ey+vB8eP1go4tdCgP3qutNPc+Yrwde5gkc=; b=BpJaaFLPkfvaR7j5qhEcAezJQ/CQ3x7neWzcD5iAiDkU3NOsV5Ojn26Nqv/lLsD60g hokD0l/nCdGLeD/y87GA7Vq2CYGVOsFKk7q0TBK7wtP1qJeaNEBhm1bBUxKuwh7t1V3E z/VnyouJnZ+XrSK0GhsgRe3pDpYaPP9bSfx45tzeypIxzxMI7tUKqBn1mtYcbdSfDwuH M0cSedgnlRNGo8CJpG9ibt//hmTjv9TLwMh1I/kveXE+WbVQMWWKd2KtDJ/ve5Jt+g2C pzCFhR9JhKtNf2PM2vT2cAmFquxn5XvGMyfzYNp2FV9P76rO4nury73mUdPpr9zOIt+k 0eGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nNWHkJY77ey+vB8eP1go4tdCgP3qutNPc+Yrwde5gkc=; b=WE2wWto1rqGG87yKwAjmwAwBCe3GiMMmGGg9ct+FOEJzcUEsBQlriqXjHX0pFTuwrf b4qo25HjRC6ekfI3TYf3jigeHbWZBJ/pk/vbJHLfa8uJGw9pxj+Orq596yqhNM0xZQNg 2oXCsBYtwD5r6Z5mxe0PtTsBm5gRYbt5sJMZWHC1kLBeS8Z+8/n3e2QYG2k6S+vM/zMv NX8onvZFIitA7VCOs56EQYxEYRNOUiTwBvJAEUy5otkr/iGmIaPywDe4lUyYEkZgTRiB rhFq+RcbXYoXRS7HmBYG1M7kHAPKTeI7IghTay6TJqNimOq3S3zq3nzZMSO9akVaarV9 6jiA== X-Gm-Message-State: AD7BkJICu5BEEbHE3kMkbCW3qLVuAXVtm3s1Ywx/MHbYc9G/cWIYjW0/9N3t0B/PJfY+MmY8IMJVzT7cN+rIrg== MIME-Version: 1.0 X-Received: by 10.107.162.144 with SMTP id l138mr20374296ioe.123.1457921311956; Sun, 13 Mar 2016 19:08:31 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Sun, 13 Mar 2016 19:08:31 -0700 (PDT) In-Reply-To: <20160314015104.GB68039@wkstn-mjohnston.west.isilon.com> References: <20160312093835.727d7197@ernst.home> <20160314013319.GA68039@wkstn-mjohnston.west.isilon.com> <20160314015104.GB68039@wkstn-mjohnston.west.isilon.com> Date: Sun, 13 Mar 2016 19:08:31 -0700 Message-ID: Subject: Re: how to recycle Inact memory more aggressively? From: Adrian Chadd To: Mark Johnston Cc: Gary Jennejohn , "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 02:08:33 -0000 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. -adrian