From: Christoph Hellwig <hch@infradead.org>
To: Waiman Long <llong@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
lizhe.67@bytedance.com, peterz@infradead.org, mingo@redhat.com,
will@kernel.org, boqun.feng@gmail.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC 1/2] rwsem: introduce upgrade_read interface
Date: Thu, 17 Oct 2024 22:06:49 -0700 [thread overview]
Message-ID: <ZxHs6WyGcJEfd_DI@infradead.org> (raw)
In-Reply-To: <a094f899-018c-4eb7-9bee-46f102a33b8e@redhat.com>
On Thu, Oct 17, 2024 at 01:36:41PM -0400, Waiman Long wrote:
> > At least for the XFS use case where direct I/O takes a share lock
> > that needs to be replaced with an exclusive one for certain kinds of
> > I/O would be useless. But then again we've survived without this
> > operation for a long time, despite the initial port bringing one over
> > from IRIX.
>
> That means XFS only needs to upgrade to a write lock in certain cases only,
> not all of them.
Yes. Basically when we detect a direct I/O writes needs to clear the
SUID bit or other metadata, or when it is an extending write.
> Right? In that case, read_try_upgrade() that attempts to
> upgrade to a write lock will be useful.
Yes. But I also understand Peters reasoning that it will be very hard
to actually have a useful implementation that does better than just
unlocking (which is what we do currently).
next prev parent reply other threads:[~2024-10-18 5:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 4:35 [RFC 0/2] rwsem: introduce upgrade_read interface lizhe.67
2024-10-16 4:35 ` [RFC 1/2] " lizhe.67
2024-10-16 4:56 ` Christoph Hellwig
2024-10-16 7:33 ` lizhe.67
2024-10-16 7:36 ` Christoph Hellwig
2024-10-16 8:00 ` lizhe.67
2024-10-16 8:03 ` Christoph Hellwig
2024-10-16 8:13 ` lizhe.67
2024-10-16 11:51 ` Matthew Wilcox
2024-10-16 12:21 ` Christoph Hellwig
2024-10-16 11:49 ` Matthew Wilcox
2024-10-17 6:23 ` lizhe.67
2024-10-16 14:23 ` Waiman Long
2024-10-16 18:05 ` Matthew Wilcox
2024-10-16 18:39 ` Waiman Long
2024-10-17 6:46 ` lizhe.67
2024-10-17 15:05 ` Christoph Hellwig
2024-10-17 17:36 ` Waiman Long
2024-10-18 5:06 ` Christoph Hellwig [this message]
2024-10-19 22:59 ` kernel test robot
2024-10-16 4:36 ` [RFC 2/2] khugepaged: use upgrade_read() to optimize collapse_huge_page lizhe.67
2024-10-16 11:53 ` Matthew Wilcox
2024-10-17 6:18 ` lizhe.67
2024-10-17 13:20 ` Matthew Wilcox
2024-10-18 6:37 ` lizhe.67
2024-10-23 7:27 ` kernel test robot
2024-10-16 8:09 ` [RFC 0/2] rwsem: introduce upgrade_read interface Peter Zijlstra
2024-10-16 8:53 ` lizhe.67
2024-10-16 12:10 ` Peter Zijlstra
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=ZxHs6WyGcJEfd_DI@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=llong@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@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.