From nobody Sat Oct 14 01:08:56 2023 X-Original-To: dev-commits-src-all@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 4S6ld43hjlz4x46Y; Sat, 14 Oct 2023 01:08:56 +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 4S6ld43CYgz3Y3b; Sat, 14 Oct 2023 01:08:56 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697245736; 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=4jy8KkVt1cINHBWydpUTp8yFQ81rdLd6wlQ0hRmRIq4=; b=t2NNTfj0aUEaFT4McErMpxEvjY5D3YB0XqldvcIsEmC7ufQbJ+x00EkgvRVIQzewV/Hzay LkHFqhyY6QW3arwVOGeEXr4GgLFeCZj63q0vWHw06u5XYtTP+BE1tSQXQ3qExKwF2nCXJH HNwx0A33uwlZSmTgv7x62Oz/KRHN67xvn6BJ5NhMbLq5CcQEAjXRpd6rErW8ORO4VPKcMn M2FZVB4njp7DiNu577qoImawFEGSVO0Y7CJfri3VNEJC74So3FPlzk7QlSa8A/r4fgdQeV H4b6zeDybQ/gricYz4nmP7Q4GkwLxzr+PBe9L9drU6qUVW3ZY21NnFj8+/PNYQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1697245736; a=rsa-sha256; cv=none; b=X56RkK/oxNnS0MeX2pzckYawqTO46H3rjheMlKxw3jZnAsZlH2OkEpEP6nHKpze/6jZOEj P6IYXJFABUqKHYDEUOWPswdPYcCT86KVpAImkwAahuYRnoXx8NCMAU9IfCqT3aLX4JUnwZ jqe9vesj76yyVR2wTxtqtzjZ6LISfM0qpVQzdLuY4QAV2xq3UJ2C2UwFB4pZqz9oXNvp8i rI1D8MOXCdBy2hpp3awDw6xilFizkci0I3VBYgYo82PLValqlcM+bHe0BqZSfn+DkmOjeC zyhu9VXu3LrBlOBSstlUfotlop5kX6KOVvoE9ke/uih7XbVNMpjnKjyzCHhPwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697245736; 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=4jy8KkVt1cINHBWydpUTp8yFQ81rdLd6wlQ0hRmRIq4=; b=IPgjA+MMa74wzNhAcJOBDPFH5SKzsA6cJUEp5eZhF4AWppCFW1Gv4xuZUitKopOIhp5KUH me2+49gFcEeo7aZFAV7WNgQ8gTk9Z0iIM4auIYeZT5iYdj5LEMycoCm6mMvhZWhignMkfD aynnMCm4NDpygi9VPRS09UITtT8ggAsw7OWt2fEzg70EAruAvS6rdgu3qhNkvuJbUBArnm uWzT2hTmhw7LbCHruvXJzGan7IOvJpaKPdHWsYkX75pDNfHqUQMgjg+kx0K3BOdT8MO6hc dwTwn0tCjHrnl/c9GRpqgv/0im0Y/qWqy/cxxT2wbICEMwSYmARyQ7YYM9LABA== 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 4S6ld426ncz191M; Sat, 14 Oct 2023 01:08:56 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.17.1/8.17.1) with ESMTP id 39E18une052549; Sat, 14 Oct 2023 01:08:56 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.17.1/8.17.1/Submit) id 39E18ucH052545; Sat, 14 Oct 2023 01:08:56 GMT (envelope-from git) Date: Sat, 14 Oct 2023 01:08:56 GMT Message-Id: <202310140108.39E18ucH052545@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: c3cf531eace6 - releng/14.0 - vfs: further speed up continuous free vnode recycle List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@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/14.0 X-Git-Reftype: branch X-Git-Commit: c3cf531eace688634b3d839a8d916b713d98d6bc Auto-Submitted: auto-generated The branch releng/14.0 has been updated by mjg: URL: https://cgit.FreeBSD.org/src/commit/?id=c3cf531eace688634b3d839a8d916b713d98d6bc commit c3cf531eace688634b3d839a8d916b713d98d6bc Author: Mateusz Guzik AuthorDate: 2023-10-11 09:42:12 +0000 Commit: Mateusz Guzik CommitDate: 2023-10-14 01:07:50 +0000 vfs: further speed up continuous free vnode recycle The primary bottleneck *was* vnode_list mtx, which got artificially worsened due to the following work done with the lock held: 1. the global heavily modified numvnodes counter was being read, inducing massive cache line ping pong 2. should the value fit limits (which it normally did) there would be an avoidable write to vn_alloc_cyclecount, which is being read outside of the lock, once more inducing traffic But if vn_alloc_cyclecount is 0, which it normally is even when facing vnode shortage, there is no need to check numvnodes nor set it to 0 again. Another problem was numvnodes adjustment (which made the locked read much worse). While it fundamentally does not scale as it is not distributed in any fashion, it was avoidably slow. When bumping over the vnode limit, it would be modified with atomics 3 times: inc + dec to backpedal in vn_alloc, then final inc in vn_alloc_hard. One can let some slop persist over calls to vnlru_free instead. In principle each thread in the system could get here and bump it, so a limit is put in place to keep things sane. Bench setup same as in prior commits: zfs, 20 separate directory trees each with 1 million files in total and 20 find(1) processes stating them in parallel (one per each tree). Total run time (in seconds) goes down as follows: vnode limit 8388608 400000 before ~20 ~35 after ~8 ~15 With this in place the primary bottleneck is now ZFS. Sponsored by: Rubicon Communications, LLC ("Netgate") (cherry picked from commit 054f45e026d898bdc8f974d33dd748937dee1d6b) (cherry picked from commit cc2d62daa33935489235a4ef253ae61676baf7c4) Approved by: re (gjb) --- sys/kern/vfs_subr.c | 46 +++++++++++++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 52c14b4a234a..99933a6b9c88 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -1490,6 +1490,8 @@ static u_long vnlruproc_kicks; SYSCTL_ULONG(_vfs_vnode_vnlru, OID_AUTO, kicks, CTLFLAG_RD, &vnlruproc_kicks, 0, "Number of times vnlru got woken up due to vnode shortage"); +#define VNLRU_COUNT_SLOP 100 + /* * The main freevnodes counter is only updated when a counter local to CPU * diverges from 0 by more than VNLRU_FREEVNODES_SLOP. CPUs are conditionally @@ -1632,7 +1634,8 @@ vnlru_proc_sleep(void) * * On a kernel with only stock machinery this needs anywhere between 60 and 120 * seconds to execute (time varies *wildly* between runs). With the workaround - * it consistently stays around 20 seconds. + * it consistently stays around 20 seconds [it got further down with later + * changes]. * * That is to say the entire thing needs a fundamental redesign (most notably * to accommodate faster recycling), the above only tries to get it ouf the way. @@ -1661,7 +1664,7 @@ vnlru_proc_light_pick(void) * the limit for a short period, don't bother doing anything in * that case. */ - if (rnumvnodes > desiredvnodes + 10) { + if (rnumvnodes > desiredvnodes + VNLRU_COUNT_SLOP + 10) { if (rnumvnodes - rfreevnodes >= desiredvnodes || rfreevnodes <= wantfreevnodes) { return (-1); @@ -1795,7 +1798,8 @@ vnlru_proc(void) * limit (see vn_alloc_hard), no need to call uma_reclaim if * this happens. */ - if (onumvnodes + 1000 > desiredvnodes && numvnodes <= desiredvnodes) + if (onumvnodes + VNLRU_COUNT_SLOP + 1000 > desiredvnodes && + numvnodes <= desiredvnodes) uma_reclaim(UMA_RECLAIM_DRAIN); if (done == 0) { if (force == 0 || force == 1) { @@ -1912,19 +1916,27 @@ SYSCTL_ULONG(_vfs_vnode_stats, OID_AUTO, alloc_sleeps, CTLFLAG_RD, &vn_alloc_sle "Number of times vnode allocation blocked waiting on vnlru"); static struct vnode * __noinline -vn_alloc_hard(struct mount *mp) +vn_alloc_hard(struct mount *mp, u_long rnumvnodes, bool bumped) { - u_long rnumvnodes, rfreevnodes; + u_long rfreevnodes; - mtx_lock(&vnode_list_mtx); - rnumvnodes = atomic_load_long(&numvnodes); - if (rnumvnodes + 1 < desiredvnodes) { - vn_alloc_cyclecount = 0; - mtx_unlock(&vnode_list_mtx); - goto alloc; + if (bumped) { + if (rnumvnodes > desiredvnodes + VNLRU_COUNT_SLOP) { + atomic_subtract_long(&numvnodes, 1); + bumped = false; + } } + mtx_lock(&vnode_list_mtx); + if (vn_alloc_cyclecount != 0) { + rnumvnodes = atomic_load_long(&numvnodes); + if (rnumvnodes + 1 < desiredvnodes) { + vn_alloc_cyclecount = 0; + mtx_unlock(&vnode_list_mtx); + goto alloc; + } + rfreevnodes = vnlru_read_freevnodes(); if (rfreevnodes < wantfreevnodes) { if (vn_alloc_cyclecount++ >= rfreevnodes) { @@ -1953,6 +1965,10 @@ vn_alloc_hard(struct mount *mp) /* * Wait for space for a new vnode. */ + if (bumped) { + atomic_subtract_long(&numvnodes, 1); + bumped = false; + } mtx_lock(&vnode_list_mtx); vnlru_kick_locked(); vn_alloc_sleeps++; @@ -1965,7 +1981,8 @@ vn_alloc_hard(struct mount *mp) } alloc: mtx_assert(&vnode_list_mtx, MA_NOTOWNED); - atomic_add_long(&numvnodes, 1); + if (!bumped) + atomic_add_long(&numvnodes, 1); vnlru_kick_cond(); return (uma_zalloc_smr(vnode_zone, M_WAITOK)); } @@ -1976,11 +1993,10 @@ vn_alloc(struct mount *mp) u_long rnumvnodes; if (__predict_false(vn_alloc_cyclecount != 0)) - return (vn_alloc_hard(mp)); + return (vn_alloc_hard(mp, 0, false)); rnumvnodes = atomic_fetchadd_long(&numvnodes, 1) + 1; if (__predict_false(vnlru_under(rnumvnodes, vlowat))) { - atomic_subtract_long(&numvnodes, 1); - return (vn_alloc_hard(mp)); + return (vn_alloc_hard(mp, rnumvnodes, true)); } return (uma_zalloc_smr(vnode_zone, M_WAITOK));