From: Jens Axboe <axboe@kernel.dk>
To: Michael Kelley <mhklinux@outlook.com>, "hch@lst.de" <hch@lst.de>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
Subject: Re: Merging raw block device writes
Date: Tue, 28 Nov 2023 14:59:45 -0700 [thread overview]
Message-ID: <66be0c42-2514-436b-bbef-3bd9ab123594@kernel.dk> (raw)
In-Reply-To: <SN6PR02MB41578DD2B7A1F25336B0224BD4BCA@SN6PR02MB4157.namprd02.prod.outlook.com>
On 11/28/23 12:29 PM, Michael Kelley wrote:
> From: Jens Axboe <axboe@kernel.dk> Sent: Monday, November 27, 2023 8:10 AM
>>
>> On 11/26/23 11:59 PM, hch@lst.de wrote:
>>> On Sat, Nov 25, 2023 at 05:38:28PM +0000, Michael Kelley wrote:
>>>> Hyper-V guests and the Azure cloud have a particular interest here
>>>> because Hyper-V guests uses SCSI as the standard interface to virtual
>>>> disks. Azure cloud disks can be throttled to a limited number of IOPS,
>>>> so the number of in-flights I/Os can be relatively high, and
>>>> merging can be beneficial to staying within the throttle
>>>> limits. Of the flip side, this problem hasn't generated complaints
>>>> over the last 18 months that I'm aware of, though that may be more
>>>> because commercial distros haven't been running 5.16 or later kernels
>>>> until relatively recently.
>>>
>>> I think the more important thing is that if you care about reducing
>>> the number of I/Os you probably should use an I/O scheduler. Reducing
>>> the number of I/Os without an I/O scheduler isn't (and I'll argue
>>> shouldn't) be a concern for the non I/O scheduler.
>>
>> Yep fully agree.
>>
>
> OK. But there *is* intentional functionality in blk-mq to do merging
> even when there's no I/O scheduler. If that functionality breaks, is
> that considered a bug and regression? The functionality only affects
> performance and not correctness, so maybe it's a bit of a gray area.
>
> It's all working again as of 6.5, so the only potential code action is to
> backport Christoph's commit to stable releases. But it still seems like
> there should be an explicit statement about what to expect going forward.
> Should the code for doing merging with no I/O scheduler be removed, or
> at least put on the deprecation path?
It's mostly a "you get what you get" thing. If we can do merging cheap
or for free, then we do that above the IO scheduler. It'd be great to
have some tests for this to ensure we don't regress, unknowingly.
But in general, if you want guaranteed good merging, then an IO
scheduler is the right choice.
--
Jens Axboe
prev parent reply other threads:[~2023-11-28 21:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-25 17:38 Merging raw block device writes Michael Kelley
2023-11-27 6:59 ` hch
2023-11-27 16:10 ` Jens Axboe
2023-11-28 19:29 ` Michael Kelley
2023-11-28 21:59 ` Jens Axboe [this message]
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=66be0c42-2514-436b-bbef-3bd9ab123594@kernel.dk \
--to=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=mhklinux@outlook.com \
/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