From: Luis Chamberlain <mcgrof@kernel.org>
To: Christoph Hellwig <hch@infradead.org>,
martin.petersen@oracle.com, ebiggers@google.com
Cc: 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: Sat, 29 Jun 2024 20:24:00 -0700 [thread overview]
Message-ID: <ZoDP0LgeLV3H1JbB@bombadil.infradead.org> (raw)
In-Reply-To: <Zn-o3jQj4RkJobjS@infradead.org>
On Fri, Jun 28, 2024 at 11:25:34PM -0700, Christoph Hellwig wrote:
> On Fri, Jun 28, 2024 at 02:23:50PM -0700, Luis Chamberlain wrote:
> > We currently rely on the block device logical block size for the
> > offset alignment. While this *works* it doesn't work with performance
> > in mind. That's exactly what the minimum_io_size attribute is for.
> >
> > This would for example enhance performance for DIO on 4k IU drives which
> > have for example an LBA format of 512 bytes for both HDDs and NVMe.
> > Another use case is to ensure that DIO will be used with 16k IOs on
> > existing market 16k IU drives with an LBA format of 4k or 512 bytes.
>
> 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?
What: /sys/block/<disk>/queue/minimum_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] Storage devices may report a granularity or preferred
minimum I/O size which is the smallest request the device can
perform without incurring a performance penalty. For disk
drives this is often the physical block size. For RAID arrays
it is often the stripe chunk size. A properly aligned multiple
of minimum_io_size is the preferred request size for workloads
where a high number of I/O operations is desired.
If this is not the right place, do we need to use a new topology entry
for the IU? Today the NVMe drive uses it for the NPWG which these days
is the IU.
> Changing this will break existing setups.
My impression was that STATX_DIOALIGN was rather new, so any new
enhancements due to the difficulties in getting DIO alignment right,
this was the right place to do so.
Let me know if you have other suggestions.
Luis
next prev parent reply other threads:[~2024-06-30 3:24 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 [this message]
2024-06-30 5:54 ` Christoph Hellwig
2024-06-30 20:42 ` Luis Chamberlain
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=ZoDP0LgeLV3H1JbB@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