From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Carlos Maiolino <cem@kernel.org>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 17/17] xfs: reduce ilock roundtrips in xfs_qm_vop_dqalloc
Date: Fri, 17 Oct 2025 05:50:43 +0200 [thread overview]
Message-ID: <20251017035043.GA29428@lst.de> (raw)
In-Reply-To: <20251016155941.GA3356773@frogsfrogsfrogs>
On Thu, Oct 16, 2025 at 08:59:41AM -0700, Darrick J. Wong wrote:
> > > ...and I guess we no longer detach dquots from live inodes now, so we
> > > really only need ILOCK_EXCL to prevent multiple threads from trying to
> > > allocate and attach a new xfs_dquot object to the same inode, right?
> >
> > Yes.
>
> I wonder then, if there /were/ two threads racing to dqattach the same
> inode, won't the radix_tree_insert return EEXIST, preventing us
> from exposing two dquot for the same id because xfs_qm_dqget will just
> loop again?
I think so.
> [Though looking at that xfs_qm_dqget -> xfs_qm_dqget_cache_insert ->
> radix_tree_insert sequence, it looks like we can also restart
> indefinitely on other errors like ENOMEM.]
Yes. I have patches fixing that as part of moving to xarrays instead
of radix trees. But I suspect a resizable hash table might actually
be the better fit, so I didn't look into submitting that quite yet.
next prev parent reply other threads:[~2025-10-17 3:50 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 2:48 cleanup quota locking Christoph Hellwig
2025-10-13 2:48 ` [PATCH 01/17] xfs: make qi_dquots a 64-bit value Christoph Hellwig
2025-10-14 23:16 ` Darrick J. Wong
2025-10-15 4:48 ` Christoph Hellwig
2025-10-13 2:48 ` [PATCH 02/17] xfs: remove xfs_dqunlock and friends Christoph Hellwig
2025-10-14 23:17 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 03/17] xfs: don't lock the dquot before return in xqcheck_commit_dquot Christoph Hellwig
2025-10-14 23:22 ` Darrick J. Wong
2025-10-15 5:00 ` Christoph Hellwig
2025-10-15 20:27 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 04/17] xfs: don't lock the dquot before return in xrep_quota_item Christoph Hellwig
2025-10-14 23:24 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 05/17] xfs: use a lockref for the xfs_dquot reference count Christoph Hellwig
2025-10-15 21:02 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 06/17] xfs: remove xfs_qm_dqput and optimize dropping dquot references Christoph Hellwig
2025-10-15 21:04 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 07/17] xfs: consolidate q_qlock locking in xfs_qm_dqget and xfs_qm_dqget_inode Christoph Hellwig
2025-10-15 21:05 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 08/17] xfs: xfs_qm_dqattach_one is never called with a non-NULL *IO_idqpp Christoph Hellwig
2025-10-14 23:27 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 09/17] xfs: fold xfs_qm_dqattach_one into xfs_qm_dqget_inode Christoph Hellwig
2025-10-15 21:13 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 10/17] xfs: return the dquot unlocked from xfs_qm_dqget Christoph Hellwig
2025-10-15 21:17 ` Darrick J. Wong
2025-10-15 21:18 ` Darrick J. Wong
2025-10-16 4:21 ` Christoph Hellwig
2025-10-13 2:48 ` [PATCH 11/17] xfs: remove q_qlock locking in xfs_qm_scall_setqlim Christoph Hellwig
2025-10-15 21:17 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 12/17] xfs: push q_qlock acquisition from xchk_dquot_iter to the callers Christoph Hellwig
2025-10-15 21:19 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 13/17] xfs: move q_qlock locking into xchk_quota_item Christoph Hellwig
2025-10-15 21:19 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 14/17] xfs: move q_qlock locking into xqcheck_compare_dquot Christoph Hellwig
2025-10-15 21:20 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 15/17] xfs: move q_qlock acquisition into xqcheck_commit_dquot Christoph Hellwig
2025-10-15 21:20 ` Darrick J. Wong
2025-10-16 4:22 ` Christoph Hellwig
2025-10-13 2:48 ` [PATCH 16/17] xfs: move xfs_dquot_tree calls into xfs_qm_dqget_cache_{lookup,insert} Christoph Hellwig
2025-10-15 21:21 ` Darrick J. Wong
2025-10-13 2:48 ` [PATCH 17/17] xfs: reduce ilock roundtrips in xfs_qm_vop_dqalloc Christoph Hellwig
2025-10-15 21:27 ` Darrick J. Wong
2025-10-16 4:23 ` Christoph Hellwig
2025-10-16 15:59 ` Darrick J. Wong
2025-10-17 3:50 ` Christoph Hellwig [this message]
2025-10-17 23:09 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251017035043.GA29428@lst.de \
--to=hch@lst.de \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.