From nobody Fri Mar 25 14:04:15 2022 X-Original-To: dev-commits-src-branches@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F70C1A3F71A; Fri, 25 Mar 2022 14:04:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ3jq2fR6z3srS; Fri, 25 Mar 2022 14:04:15 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648217055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=BEv9G/2iagJtn9/h/fRYTMJr/Cp2tb03h/0F3gpzrxU=; b=qNs4UlcavBpxbQ+b4TiaUyZ3fj/u4KjGKx9H1vBeycbUsezPLzQxEgAJgvB+VQXkLSSNnw uoBH43KQaEsFdm0oOyUR9qpqqNfYrrHltGMYxsgWunq6L7Zej7HsoTe+ht96yEE4Zvm87n arkon9hsE8tmSR2B9qbZ4FxBWE4SIMazcgc3zDK7wq9W7qksWbzIZABIISFU06fYYIvZ7f KG6qFSLVJLVk7rCstEwabbKGEzxLwXPY06IeS/m/zRbRYZd0Gu7aFffTbAVDQz6hTunv1f GmXr50Tskaz3jUvh7CAAMNwRKpV/CZ1CIUDy1o7RuLZrd9aJzoxdzmJ2mODeIA== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 14FEB5C64; Fri, 25 Mar 2022 14:04:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 22PE4FVB059218; Fri, 25 Mar 2022 14:04:15 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 22PE4FMe059217; Fri, 25 Mar 2022 14:04:15 GMT (envelope-from git) Date: Fri, 25 Mar 2022 14:04:15 GMT Message-Id: <202203251404.22PE4FMe059217@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org From: Mateusz Guzik Subject: git: 115479c27d2a - releng/13.1 - vfs: [2/2] fix stalls in vnode reclaim by only counting attempts List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-branches@freebsd.org X-BeenThere: dev-commits-src-branches@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: mjg X-Git-Repository: src X-Git-Refname: refs/heads/releng/13.1 X-Git-Reftype: branch X-Git-Commit: 115479c27d2a6bcb263ac8aab1c1eec4daa64eba Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648217055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=BEv9G/2iagJtn9/h/fRYTMJr/Cp2tb03h/0F3gpzrxU=; b=azKjPzR2ppMLPdXvZPDbCU5s9UFLBiCHwkfOvXxRmTslGICDuKkHBSLJMG71RzjJkHrqTa rDrQq4fTRn2Bp6REOw1oStC/kl95xjaEAjGNVrRz+7aM2/3JUD9Np01SHIrIaW1OC5b+Ob xA1KEuPRwsq0yzJn15sEQ9cRQ0WSWBb+ndzU8FZWM5fzocep84Ge/rVuNKZ6dNtWT2eE4u kZwsQMpJ3TQ4csbXNr9YpB/+26CwKYsw2RDTTQMNPNxuIPIKr3SO1IrYcqOq0SIvVPYw9c keqqIgSRxkZh0qUL/T/F007AO9QX69GZr8IWQRxsTzL79ywI23FoDRrKjrT6CQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648217055; a=rsa-sha256; cv=none; b=unceS53RFNs74RTap9XMHnx8+U5JAsOUdqYqL+f3GfF/Nd1QMBGy+JWuVFYi0SKpjvoiMs HMWEBSW+lRerZcJ3Ql4g6AvJ9kcbDhPdkryG4KX3NKNIN3plC8Thstnt5Dw4euknJ5Puck PqGx6shP6iKOZghEh4yTIpCDFt9BfQ8CxtOC1z+2cahyk7ozOk6gIxkoh6D+nYcJs8VXNm S9q3TznSMo1EzPGyRA1+uO60xy8yuUxlnmn5hwdb73lL0VXbVc47WkC6M7uOBvNswPotm/ rZFbuFRkTNJ3gtpvgfUh2HTtCUER8J/MKZds+yO88NOQnQZK2Ihy1+Tvt2xKog== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch releng/13.1 has been updated by mjg: URL: https://cgit.FreeBSD.org/src/commit/?id=115479c27d2a6bcb263ac8aab1c1eec4daa64eba commit 115479c27d2a6bcb263ac8aab1c1eec4daa64eba Author: Mateusz Guzik AuthorDate: 2022-03-07 10:38:17 +0000 Commit: Mateusz Guzik CommitDate: 2022-03-25 14:04:00 +0000 vfs: [2/2] fix stalls in vnode reclaim by only counting attempts ... and ignoring if they succeded, which matches historical behavior. Reported by: pho Approved by: re (gjb) (cherry picked from commit 3a4c5dab9266fac93a5cb22c7cee3938466aedea) --- sys/kern/vfs_subr.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 5c5faf455f2b..d27e7a15d886 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -1307,8 +1307,29 @@ vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp) TAILQ_REMOVE(&vnode_list, mvp, v_vnodelist); TAILQ_INSERT_AFTER(&vnode_list, vp, mvp, v_vnodelist); mtx_unlock(&vnode_list_mtx); - if (vtryrecycle(vp) == 0) - count--; + /* + * FIXME: ignores the return value, meaning it may be nothing + * got recycled but it claims otherwise to the caller. + * + * Originally the value started being ignored in 2005 with + * 114a1006a8204aa156e1f9ad6476cdff89cada7f . + * + * Respecting the value can run into significant stalls if most + * vnodes belong to one file system and it has writes + * suspended. In presence of many threads and millions of + * vnodes they keep contending on the vnode_list_mtx lock only + * to find vnodes they can't recycle. + * + * The solution would be to pre-check if the vnode is likely to + * be recycle-able, but it needs to happen with the + * vnode_list_mtx lock held. This runs into a problem where + * VOP_GETWRITEMOUNT (currently needed to find out about if + * writes are frozen) can take locks which LOR against it. + * + * Check nullfs for one example (null_getwritemount). + */ + vtryrecycle(vp); + count--; mtx_lock(&vnode_list_mtx); vp = mvp; }