From owner-svn-src-head@freebsd.org Tue Apr 10 15:17:39 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 786ADF8004D; Tue, 10 Apr 2018 15:17:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 0AA0B853D1; Tue, 10 Apr 2018 15:17:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id o4so14097639iod.3; Tue, 10 Apr 2018 08:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7ZG8VPnm7ia40tPK+biKdB0HSXwTeSWZl/Jh539jx9M=; b=mYreIj9gyoM6FnO9TpR3FQqzA+HD+e2fyPJR2ykhYIVQpigbBGe/6Gy0ZSxRuZx94d 4QIhtw7uymb4GUWXw3/mgxA8rh0K+WMZwLNTb4AQLQOL97O9MwpxOuCuBYVG54bNWdbl EllAKg/UlguBVXSasZMmjQoxLXbK6rEv0zqGnVdlAeSQLbwdv/hy6tCrsewJIR1D+UcP KtzytywOy584zFKGrajtJYjGP5nmczASF0kPH5CpgzaH3n4EjJHVPNMoWF1/TYcuPnse v6POB4w1z+ItzBTn/IZCC4oatX/o5dSd07FXZzmTyv/Pc/zyNu5rA3dE1vhIOh+hUWz7 ut+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=7ZG8VPnm7ia40tPK+biKdB0HSXwTeSWZl/Jh539jx9M=; b=h41AEwV4eihu7DzyRo+3hQeu6NqKnESKUC+16Ubyed/DixVXw1IX3+1dCoisCEg0Vq V5hKVn3110wj+RFM5piR6t+Kcr9jo8vjzUHa2uskDTLRKb7a1kJW8gvFra41MZlJoLUj VuRMBIh74yA4BaGSvrBw5EuSryJaLl6aAEAU6V06CE6tM2vDFdXzHrn8HN+adjNOKc4g v8iYLSCY4wiaT3Vf98Kk0PpYJW3klgrnVNIBrnBR7AV66M3xbY8k3RsEvKBkaHxlyiAc zXmtlmriEVUbkIfRXwRPOBs63scJWRU7mPgnAa/T9VygF0REwgJkY5PcagRFFt/cxFeF 3X+w== X-Gm-Message-State: ALQs6tDeWv6OPZVuJxvwpb2WLV+EZYHhscjOoW5ytLWJ06Vk9rIGQ+ka pvBxOM4vlcvRr4EK/BTrn8oMiw== X-Google-Smtp-Source: AIpwx492rDXUX7o2M+f1FMMHe2rRBDLRTu9b/78gByz62A5SW914jaerm6jtKcziqJfADJjShD41AQ== X-Received: by 10.107.135.157 with SMTP id r29mr919413ioi.248.1523373458360; Tue, 10 Apr 2018 08:17:38 -0700 (PDT) Received: from raichu (toroon0560w-lp130-04-184-145-252-74.dsl.bell.ca. [184.145.252.74]) by smtp.gmail.com with ESMTPSA id n142-v6sm1023053itn.38.2018.04.10.08.17.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 08:17:37 -0700 (PDT) Sender: Mark Johnston Date: Tue, 10 Apr 2018 11:17:33 -0400 From: Mark Johnston To: Slawa Olhovchenkov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r332365 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <20180410151733.GA64021@raichu> References: <201804101356.w3ADu6Jr072766@repo.freebsd.org> <20180410140957.GG6612@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410140957.GG6612@zxy.spb.ru> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 15:17:39 -0000 On Tue, Apr 10, 2018 at 05:09:57PM +0300, Slawa Olhovchenkov wrote: > On Tue, Apr 10, 2018 at 01:56:06PM +0000, Mark Johnston wrote: > > > Author: markj > > Date: Tue Apr 10 13:56:06 2018 > > New Revision: 332365 > > URL: https://svnweb.freebsd.org/changeset/base/332365 > > > > Log: > > Set zfs_arc_free_target to v_free_target. > > > > Page daemon output is now regulated by a PID controller with a setpoint > > of v_free_target. Moreover, the page daemon now wakes up regularly > > rather than waiting for a wakeup from another thread. This means that > > the free page count is unlikely to drop below the old > > zfs_arc_free_target value, and as a result the ARC was not readily > > freeing pages under memory pressure. Address the immediate problem by > > updating zfs_arc_free_target to match the page daemon's new behaviour. > > Can you explain some more about new page daemon algo (and reclaim zone > free memory)? The old algorithm was pretty simple: there was a free page target and below that, a wakeup threshold. Any time a thread allocated a page and in so doing caused the free page count to drop below the wakeup threshold, that thread would wake up the page daemon, which would scan the inactive queue and free pages until the free target is reached, or the end of the inactive queue was reached. This is simple and easy to reason about, but has some drawbacks. When memory pressure is constant, it leads to bursts of CPU usage and lock contention. The static watermarks may also be insufficient for some demanding workloads. In particular, the wakeup threshold might be too low, thus allowing the free page count to drop to dangerous levels and triggering expensive memory shortage handling (i.e., VM_WAIT). The new algorithm uses a control loop to dynamically compute a target for each scan of the inactive queue. The loop takes as input the magnitude of the page shortage (v_free_target - v_free_count) and keeps track of the rate of change of this difference (i.e., the rate at which free pages are being consumed) and the sum of this difference over time (i.e., a cumulative value for the magnitude of recent page shortages). These factors are used to compute "shortage", the number of pages to reclaim with the goal of maintaining a free page count of v_free_target. The effect of the new algorithm is that the page daemon runs more frequently but for shorter durations, so its CPU usage is more even. It responds dynamically to the demands of the workload, so the shortcomings of a pair of static watermarks are gone. r329882 doesn't really change anything with respect to reclamation of pages from UMA zones. There are some plans to address shortcomings there in the near future though. > PS: zfs need some more time for free pages from ARC. Also, vanila zfs > have broken logic for count used and free ARC's memory. For most > correctly count system-wide used and free memory need accounting > in-zone free memory. Yes, there is a number of problems in this area predating r329882. This commit is really just a bandaid.