From owner-svn-src-head@freebsd.org Sat Mar 31 22:54:37 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 D9533F5CC90; Sat, 31 Mar 2018 22:54:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 6EE4C7ABF9; Sat, 31 Mar 2018 22:54:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io0-x234.google.com with SMTP id m83so14424022ioi.8; Sat, 31 Mar 2018 15:54:36 -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=P4l/Wjtvw9z3v+iiZ9Rc/VieHpnq0sm1JTa2GWSSikY=; b=WwkoTGgBUcJIMdknbRGb5yCvVmtz5BD4lkAHWGRioaphuigfgev139eJgufVh0DJRx HK3l7hpq7oQBdSFwtWpEgXj9Ih3/+E5WAedI9bkAGt/wfYiEi0WxATQOY/pjDl3H+wDL FMddNxSpXpCC7NiXAj273wnZqmknco5iKxDeKbH8KPt5aGI9nzw8xI85+W6UMzCj6r83 DGopkI5IDUYL38yXFuo0rDuTKBUSObbXR/3dhU+sUWF03e0BjSTzBVfvpzUdiHVRpvXu VW9S1Qgl6naOy6KTdYLwUsbaFxgbVUIWwNMjR70pOkbUly0FOW+2X9fWSxeH/8+bYcR9 oGdA== 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=P4l/Wjtvw9z3v+iiZ9Rc/VieHpnq0sm1JTa2GWSSikY=; b=jikPnf+TPYsxw+oEIJp1F+TBFmYaUUzBz06dsXNnzu2XB9TlhEXMR3DKC+FR+KlMJC xD37IiCX2if7thw/kdbpMZ9ClpWubFRqNrAJ474lzsq47LNBVLtZKigQsJE1NO7BvJcF FBD+L5j2vqJybqRWNgMs+qxpkbwBsxcZ82u0CIdKUYYfUG7pawVWyTsHPKKv0oaJcJdg uGLTybj7SMS240uFu9L98XQwUqq+8v+qGXoDCQLu1gniJi1DTKFodI3+sJiRSWShcVge xz5oISP1n+eUL0JplnJjI+mVH7JnJ08GOm1CiuCt/1hBTb+YlAQXae/Ycz1kSgvxA+90 vJ5A== X-Gm-Message-State: AElRT7Hr8lQ/kU7j/KzQvrkC1B8KVt05y3+ErP/XAAtdzDFQD9MHoTYv 9HBkr9Bmylz6XCQMftz/IIlfPA== X-Google-Smtp-Source: AIpwx49mrF5PdNUUHXy7tLThiZ7K5UizcWX/t1CwyyKZBHYfLO3rTw2Dzgr27ta/SYcBCXTMg2Rxlw== X-Received: by 10.107.134.140 with SMTP id q12mr3638866ioi.92.1522536875557; Sat, 31 Mar 2018 15:54:35 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-76-83.dsl.bell.ca. [174.88.76.83]) by smtp.gmail.com with ESMTPSA id 134-v6sm3857965itl.34.2018.03.31.15.54.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 15:54:34 -0700 (PDT) Sender: Mark Johnston Date: Sat, 31 Mar 2018 18:54:32 -0400 From: Mark Johnston To: Tijl Coosemans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r331732 - head/sys/vm Message-ID: <20180331225432.GB1440@raichu> References: <201803291427.w2TEReA3024929@repo.freebsd.org> <20180331202118.5401ed2a@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180331202118.5401ed2a@kalimero.tijl.coosemans.org> 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: Sat, 31 Mar 2018 22:54:37 -0000 On Sat, Mar 31, 2018 at 08:21:18PM +0200, Tijl Coosemans wrote: > On Thu, 29 Mar 2018 14:27:40 +0000 (UTC) Mark Johnston wrote: > > Author: markj > > Date: Thu Mar 29 14:27:40 2018 > > New Revision: 331732 > > URL: https://svnweb.freebsd.org/changeset/base/331732 > > > > Log: > > Fix the background laundering mechanism after r329882. > > > > Rather than using the number of inactive queue scans as a metric for > > how many clean pages are being freed by the page daemon, have the > > page daemon keep a running counter of the number of pages it has freed, > > and have the laundry thread use that when computing the background > > laundering threshold. > > [...] > > I'm seeing big processes being killed with an "out of swap space" message > even though there's still plenty of swap available. It seems to be fixed > by making this division round upwards: > > if (target == 0 && ndirty * isqrt((nfreed + > (vmd->vmd_free_target - vmd->vmd_free_min) - 1) / > (vmd->vmd_free_target - vmd->vmd_free_min)) >= nclean) { > > I don't know where this formula comes from, so I don't know if this > change is correct. Hm, that's somewhat surprising. This code shouldn't be executing in situations where the OOM kill logic is invoked (i.e., memory pressure plus a shortage of clean pages in the inactive queue). How much RAM does the system have? Could you collect "sysctl vm" output around the time of an OOM kill? I'm wondering if the higher inactive queue scan frequency after r329882 might be responsible: OOM kills are performed after vm.pageout_oom_seq back-to-back scans fail to reclaim any pages. Does your problem persist if you increase the value of that sysctl, say to 60?