From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
Chi Zhiling <chizhiling@163.com>,
Amir Goldstein <amir73il@gmail.com>,
Dave Chinner <david@fromorbit.com>,
cem@kernel.org, linux-xfs@vger.kernel.org,
linux-kernel@vger.kernel.org, Chi Zhiling <chizhiling@kylinos.cn>,
John Garry <john.g.garry@oracle.com>
Subject: Re: [PATCH] xfs: Remove i_rwsem lock in buffered read
Date: Tue, 14 Jan 2025 21:55:21 -0800 [thread overview]
Message-ID: <Z4dNyZi8YyP3Uc_C@infradead.org> (raw)
In-Reply-To: <Z4UX4zyc8n8lGM16@bfoster>
On Mon, Jan 13, 2025 at 08:40:51AM -0500, Brian Foster wrote:
> Sorry if this is out of left field as I haven't followed the discussion
> closely, but I presumed one of the reasons Darrick and Christoph raised
> the idea of using the folio batch thing I'm playing around with on zero
> range for buffered writes would be to acquire and lock all targeted
> folios up front. If so, would that help with what you're trying to
> achieve here? (If not, nothing to see here, move along.. ;).
I mostly thought about acquiring, as locking doesn't really have much
batching effects. That being said, no that you got the idea in my mind
here's my early morning brainfart on it:
Let's ignore DIRECT I/O for the first step. In that case lookup /
allocation and locking all folios for write before copying data will
remove the need for i_rwsem in the read and write path. In a way that
sounds perfect, and given that btrfs already does that (although in a
very convoluted way) we know it's possible.
But direct I/O throws a big monkey wrench here as already mentioned by
others. Now one interesting thing some file systems have done is
to serialize buffered against direct I/O, either by waiting for one
to finish, or by simply forcing buffered I/O when direct I/O would
conflict. It's easy to detect outstanding direct I/O using i_dio_count
so buffered I/O could wait for that, and downgrading to buffered I/O
(potentially using the new uncached mode from Jens) if there are any
pages on the mapping after the invalidation also sounds pretty doable.
I don't really have time to turn this hand waving into, but maybe we
should think if it's worthwhile or if I'm missing something important.
next prev parent reply other threads:[~2025-01-15 5:55 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-26 6:16 [PATCH] xfs: Remove i_rwsem lock in buffered read Chi Zhiling
2024-12-26 21:50 ` Dave Chinner
2024-12-28 7:37 ` Chi Zhiling
2024-12-28 22:17 ` Dave Chinner
2024-12-30 2:42 ` Chi Zhiling
2025-01-07 12:13 ` Amir Goldstein
2025-01-07 17:12 ` Christoph Hellwig
2025-01-08 7:43 ` Chi Zhiling
2025-01-08 11:33 ` Amir Goldstein
2025-01-08 11:45 ` Amir Goldstein
2025-01-08 12:15 ` John Garry
2025-01-09 10:07 ` Amir Goldstein
2025-01-09 12:40 ` John Garry
2025-01-09 8:37 ` Chi Zhiling
2025-01-09 10:25 ` Amir Goldstein
2025-01-09 12:10 ` Chi Zhiling
2025-01-09 12:25 ` John Garry
2025-01-08 17:35 ` Darrick J. Wong
2025-01-09 23:28 ` Dave Chinner
2025-01-10 1:31 ` Chi Zhiling
2025-01-10 17:07 ` Amir Goldstein
2025-01-12 10:05 ` Chi Zhiling
2025-01-13 2:44 ` Darrick J. Wong
2025-01-13 5:59 ` Chi Zhiling
2025-01-13 13:40 ` Brian Foster
2025-01-13 16:19 ` Darrick J. Wong
2025-01-15 5:55 ` Christoph Hellwig [this message]
2025-01-15 21:41 ` Dave Chinner
2025-01-16 4:36 ` Christoph Hellwig
2025-01-17 22:20 ` Dave Chinner
2025-01-16 14:23 ` Brian Foster
2025-01-17 13:27 ` Amir Goldstein
2025-01-17 22:19 ` Dave Chinner
2025-01-18 13:03 ` Amir Goldstein
2025-01-20 5:11 ` Dave Chinner
2025-01-22 6:08 ` Christoph Hellwig
2025-01-22 23:35 ` Dave Chinner
2025-01-17 16:12 ` Chi Zhiling
2025-01-24 7:57 ` Chi Zhiling
2025-01-27 20:49 ` Dave Chinner
2025-01-28 5:15 ` Christoph Hellwig
2025-01-28 21:23 ` David Laight
2025-01-29 0:59 ` Dave Chinner
2025-01-29 5:20 ` Christoph Hellwig
2025-02-10 1:44 ` Chi Zhiling
2025-01-14 0:09 ` Dave Chinner
2025-01-25 8:43 ` Jinliang Zheng
2025-01-25 14:14 ` Amir Goldstein
2025-06-20 14:03 ` Jinliang Zheng
-- strict thread matches above, loose matches on Subject: below --
2019-03-25 0:10 [QUESTION] Long read latencies on mixed rw buffered IO Dave Chinner
2025-06-20 13:46 ` [PATCH] xfs: Remove i_rwsem lock in buffered read Jinliang Zheng
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=Z4dNyZi8YyP3Uc_C@infradead.org \
--to=hch@infradead.org \
--cc=amir73il@gmail.com \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=chizhiling@163.com \
--cc=chizhiling@kylinos.cn \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).