From: Christoph Hellwig <hch@lst.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Chandan Babu R <chandan.babu@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Hongbo Li <lihongbo22@huawei.com>,
Ryusuke Konishi <konishi.ryusuke@gmail.com>,
linux-nilfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/3] fs: add STATX_DIO_READ_ALIGN
Date: Thu, 29 Aug 2024 05:44:26 +0200 [thread overview]
Message-ID: <20240829034426.GA3854@lst.de> (raw)
In-Reply-To: <20240828235227.GB558903@google.com>
On Wed, Aug 28, 2024 at 11:52:27PM +0000, Eric Biggers wrote:
> Thanks. We maybe should have included read/write separation in STATX_DIOALIGN,
> but at the time the only case that was brought up was "DIO reads are supported
> but DIO writes are not" which people had argued was not useful.
>
> Is this patch meant to support that case,
Why would anyone support direct I/O reads but not writes? That seems
really weird, but maybe I'm missing something important.
> or just the case where DIO in both
> directions is supported but with different alignments? Is that different file
> offset alignments, different memory alignments, or both? This patch doesn't add
> a stx_dio_read_mem_align field, so it's still assumed that both directions share
> the existing stx_dio_mem_align property, including whether DIO is supported at
> all (0 vs. nonzero).
Yes. The memory alignment really is dependent on the underlying storage
hardware DMA engine, which doesn't distinguish between reads and writes.
> So as proposed, the only case it helps with is where DIO
> in both directions is supported with the same memory alignment but different
> file offset alignments.
Yes.
> Maybe that is intended, but it's not clear to me.
Well, that's good feedback to make it more clear.
> Are there specific userspace applications that would like to take advantage of a
> smaller value of stx_dio_read_offset_align compared to the existing
> stx_dio_offset_align?
There are a lot of read-heavy workloads where smaller reads do make
a difference.
next prev parent reply other threads:[~2024-08-29 3:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 5:11 RFC: add STATX_DIO_READ_ALIGN Christoph Hellwig
2024-08-28 5:11 ` [PATCH 1/3] fs: reformat the statx definition Christoph Hellwig
2024-08-28 16:20 ` Darrick J. Wong
2024-08-28 5:11 ` [PATCH 2/3] fs: add STATX_DIO_READ_ALIGN Christoph Hellwig
2024-08-28 16:24 ` Darrick J. Wong
2024-08-28 23:52 ` Eric Biggers
2024-08-29 3:44 ` Christoph Hellwig [this message]
2024-08-28 5:11 ` [PATCH 3/3] xfs: report the correct read/write dio alignment for reflinked inodes Christoph Hellwig
2024-08-28 16:23 ` Darrick J. Wong
2024-08-29 1:13 ` Dave Chinner
2024-08-28 13:43 ` RFC: add STATX_DIO_READ_ALIGN Christian Brauner
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=20240829034426.GA3854@lst.de \
--to=hch@lst.de \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=djwong@kernel.org \
--cc=ebiggers@kernel.org \
--cc=jack@suse.cz \
--cc=konishi.ryusuke@gmail.com \
--cc=lihongbo22@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.