From nobody Mon Oct 6 19:33:05 2025 X-Original-To: dev-commits-src-main@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 4cgTvm1lYhz6BRPk for ; Mon, 06 Oct 2025 19:33:24 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cgTvl6kPTz3DVw for ; Mon, 06 Oct 2025 19:33:23 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b00a9989633so713151066b.0 for ; Mon, 06 Oct 2025 12:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759779198; x=1760383998; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8gNuIH7hFkdJfYxSs2JF8VmNzFHstUAixARC6/lOWT0=; b=IF7wgnKrHqaldSKY0zuL9491zZ+65B/IjjtWsgJFeN5sInSL4lp7tgw9fdfu4/mEJq Kud0EZl7ZCqmozosf3jVzWfzvLDbc4BDPusItz0aJFUVVnwdiTLkPG0fAAZ3smOMDO0l s5URkAOh4RUtzVnD+qru8AXtzaZhFiikjDRvfPIxjiXDj9YDRdFXNIvKCJGqQby4o5EJ x+QkgaMfW3gEeXq0H42JTwU7zuv2daoiClFE3KbFF00POYVkImMyhRRQmsEejg/zlChY LKG7jHVL+j8cEljiPi8Rb+l2KMqS/dHhcRQINE1RryQgAfLXYHbCciuCgqu4H4oHdIEb V4lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759779198; x=1760383998; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8gNuIH7hFkdJfYxSs2JF8VmNzFHstUAixARC6/lOWT0=; b=nLL0HKV91jsqBqQLVQiw2lpi8RKNydJf3zAKrwlvmAhK8v4RhuLpcmaSJ5AL6aDXAV Qqsxy4TPKJukSf9goTEjoLW5/qU2tD+IUSKKI5RUnJmxth4Q3Y70IspWKdh44ek0eRCE hz7mRntNHSbRLx91NMuy2fNPsoqXVXyPYhhXxelZCeyQBVjZZW8o4S0jYSrrg3j45kJf oDV8hw2Lqg2BUKfanrLI0T0HpPYI6wwJACTBegWKcOZiohlRBWqYKC6h9Twp8+BUt+Y7 5BBpn9g4pi9JNdMXf9agKx4yQwtEgbvYhRy/BUp3+1cxCNjcmJ+3Km6or5F61/A3Sr5H pYXg== X-Forwarded-Encrypted: i=1; AJvYcCVBZKXjoSALy8amTiFaGC3E+DrFI/HCMQ0swXCf2kGb+p6D+nfd+Y38iKwANRR/1Z8hrS76WtAGOUysR4NIMJ67xN5H1g==@freebsd.org X-Gm-Message-State: AOJu0YxqtSoehw9LzBDr6p5qtLbZD8FOgQFsHqCHicJkQzvCy0aXhi9c WT4kbfDLnbjqJHi/hkafgc1jABPGJqD+Lzs6ONSgWaeefdPSMS9Z2/AINSZ+pqmYrXaadHeZdx2 nADbb6ApdMV9FjvsrA/VNYLUFpBoLU8U= X-Gm-Gg: ASbGncsolVr2cCfd13IahGvN15RI9gq0dyCqWFpqZCO7M75gg35jA6XAd3wQ9FYkCjE l0pZw/gRJnKJYQin0KHOuyKKYYUjYeMBgR7oiq+ISvgA4o6vODTdNZkqBuU9XfP47PzB4Kfkbyg XXA89xZSMXtVfPMxWy4BxyQsXXcGAVBTn2krU9YEu0/RJSjQFOoDFgjqM/P+y6ckYp9zl+aYh4S CH7ciFM7PM+cUsBS0xkV4sDIpBMSViBLhTV535F1QUpOj4GFDhtNV0j0dcuvdC5ghYswgVDIg== X-Google-Smtp-Source: AGHT+IETT/Ydf64xdeK8TsYBFX5mMGpmL777brIj1G4uxulKLPxyUGYVd09Kagqg3GAMAMDlGJCUQb5mfsUfVl7NrNc= X-Received: by 2002:a17:907:ca20:b0:b3a:8d34:7f71 with SMTP id a640c23a62f3a-b4f42dfccbemr73171166b.32.1759779197342; Mon, 06 Oct 2025 12:33:17 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202510061522.596FMk6Q043852@gitrepo.freebsd.org> In-Reply-To: <202510061522.596FMk6Q043852@gitrepo.freebsd.org> From: Mateusz Guzik Date: Mon, 6 Oct 2025 21:33:05 +0200 X-Gm-Features: AS18NWAQcJ83J7VI2f6FznMWeA4SFhTbTU93RK2I7rjDc_GA-AbiI95yrqPbhSs Message-ID: Subject: Re: git: 09f925b57aeb - main - nullfs: Slightly reduce contention by reducing concurrent sections To: Olivier Certner Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cgTvl6kPTz3DVw On Mon, Oct 6, 2025 at 5:22=E2=80=AFPM Olivier Certner w= rote: > > The branch main has been updated by olce: > > URL: https://cgit.FreeBSD.org/src/commit/?id=3D09f925b57aeb171318a9d54df5= 00bf22b4cdd986 > > commit 09f925b57aeb171318a9d54df500bf22b4cdd986 > Author: Olivier Certner > AuthorDate: 2025-10-06 13:22:13 +0000 > Commit: Olivier Certner > CommitDate: 2025-10-06 15:21:45 +0000 > > nullfs: Slightly reduce contention by reducing concurrent sections > > In null_lock_prep_with_smr(), initialize 'lvp' outside of the > SMR-protected section. > > In null_lock(), if after locking the lower vnode we notice that we ha= ve > been reclaimed, we have to unlock the lower vnode and then relock our > own now that the lock isn't shared anymore. Call VOP_UNLOCK() on the > lower vnode as soon as this condition is known. > [snip] > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > index 375b6aa27531..ec8a6b10b13f 100644 > --- a/sys/fs/nullfs/null_vnops.c > +++ b/sys/fs/nullfs/null_vnops.c > @@ -788,10 +788,10 @@ null_lock_prep_with_smr(struct vop_lock1_args *ap) > struct null_node *nn; > struct vnode *lvp; > > - vfs_smr_enter(); > - > lvp =3D NULL; > > + vfs_smr_enter(); > + This bit is basically cosmetics. > nn =3D VTONULL_SMR(ap->a_vp); > if (__predict_true(nn !=3D NULL)) { > lvp =3D nn->null_lowervp; > @@ -855,6 +855,8 @@ null_lock(struct vop_lock1_args *ap) > * case by reacquiring correct lock in requested mode. > */ > if (VTONULL(ap->a_vp) =3D=3D NULL && error =3D=3D 0) { > + VOP_UNLOCK(lvp); > + > flags =3D ap->a_flags; > ap->a_flags &=3D ~LK_TYPE_MASK; > switch (flags & LK_TYPE_MASK) { > @@ -869,7 +871,6 @@ null_lock(struct vop_lock1_args *ap) > panic("Unsupported lock request %d\n", > flags); > } > - VOP_UNLOCK(lvp); > error =3D vop_stdlock(ap); > } > vdrop(lvp); This does not shorten the hold time in any capacity for real workloads because the vnode getting doomed from under you is a just a corner case you are not expected to run into. If someone is looking to microoptimize this, __predict true/false could be sprinkled through the entire thing. If someone is looking to create a speed up measurable in a microbenchmark, then nullfs vs vhold/vdrop business could be reworked so that locking always holds and unlocking always vdrops. Then any lock-protected VOP does not have to repeat the dance. A real-world win would come from implementing write-free lookup (modulo the last path component), like for zfs/ufs/tmpfs. It could work by lower filesystems opting it with a dedicated vop for lookups. Then you would do the lookup using the namecache entry from the lower fs and use the nullfs hash to get back to a nullfs vnode. Rinse & repeat until encountering a mount point or finding the final vnode.