From: Luis Chamberlain <mcgrof@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: martin.petersen@oracle.com, ebiggers@google.com,
p.raghav@samsung.com, hare@suse.de, kbusch@kernel.org,
david@fromorbit.com, neilb@suse.de, gost.dev@samsung.com,
linux-block@vger.kernel.org, linux-mm@kvack.org,
patches@lists.linux.dev
Subject: Re: [RFC] bdev: use bdev_io_min() for statx DIO min IO
Date: Sun, 30 Jun 2024 13:42:45 -0700 [thread overview]
Message-ID: <ZoHDRfMomK8hnDXI@bombadil.infradead.org> (raw)
In-Reply-To: <ZoDzC1qlEYTBkLPA@infradead.org>
On Sat, Jun 29, 2024 at 10:54:19PM -0700, Christoph Hellwig wrote:
> On Sat, Jun 29, 2024 at 08:24:00PM -0700, Luis Chamberlain wrote:
> > > The minimum_io_size clearly is the minimum I/O size, not the minimal
> > > nice to have one.
> >
> > I may have misread the below documentation then, because it seems to
> > suggest this is a performance parameter, not a real minimum. Do we need
> > to update it?
>
> queue_limits.min_io is corretly described and a performance hint.
OK, great!
> The statx dio_offset_align is actual minimum I/O size and alignment and
> not in any way related to the performance hint in minimum_io_size.
Oh, darn, I just read again 825cf206ed510 ("statx: add direct I/O
alignment information") and the block layer change through commit
2d985f8c6b91b ("vfs: support STATX_DIOALIGN on block devices") and
no where do I see any mention of it being a min. Should we clarify
that?
And should we add a respective value for performance? I suspect
userspace will want to work with optimal values, not ones which could
for instance incur read-modify-write. Altough we have BLKIOMIN to get
the optimal performance min IO and BLKIOOPT to get the optimal size it
is not terribly clear to me that users know they should prefer to align
to BLKIOMIN and use that for an DIO size for writes when possible.
Luis
next prev parent reply other threads:[~2024-06-30 20:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 21:23 Luis Chamberlain
2024-06-29 6:25 ` Christoph Hellwig
2024-06-30 3:24 ` Luis Chamberlain
2024-06-30 5:54 ` Christoph Hellwig
2024-06-30 20:42 ` Luis Chamberlain [this message]
2024-06-30 22:35 ` Dave Chinner
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=ZoHDRfMomK8hnDXI@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=david@fromorbit.com \
--cc=ebiggers@google.com \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.petersen@oracle.com \
--cc=neilb@suse.de \
--cc=p.raghav@samsung.com \
--cc=patches@lists.linux.dev \
/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