From: Jens Axboe <axboe@xxxxxxxxx> Sent: Monday, November 27, 2023 8:10 AM > > On 11/26/23 11:59 PM, hch@xxxxxx 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? Michael
