Arch Linux

https://bbs.archlinux.org/viewtopic.php?pid=1724475#p1724475
https://bugs.archlinux.org/task/57496
This would also switch the default scheduler from cfq to mq-deadline for devices that do not by default use the MQ schedulers.
Is there any benefit to such a switch beyond its the default from upstream?

The https://bugs.archlinux.org/task/57496 seems to be about bfq not blk-mq.

Also the devs were aware about issues. They originally planned to switch the default in 4.13 but reverted it during rc cycle. Now they are confident about it and the default made it into 4.19 stable release.

The benefit should be better performance on devices that support multi queue. Also the plan is to get rid of legacy non-blk-mq interfaces from kernel completely. Perhaps some distros will keep it until the last line of code is removed from the kernel but Arch doesn't fit for it.

For example similar CONFIG_DM_MQ_DEFAULT option is going to be removed completely in 4.20 and there will be no choice other than blk-mq:
https://github.com/torvalds/linux/commit/6a23e05c2fe3c64ec012fd81e51e3ab51e4f2f9f

BFQ in the kernel means using block MQ. If a device does not use MQ it can not trigger bugs in MQ schedulers.
DM_MQ is relevant to only the multipath target https://bugzilla.kernel.org/show_bug.cgi?id=195621. There exist devices that use scsi_mod and have multiple hardware queues?

BFQ is one of BLK-MQ available schedulers but not the default one. Enabling it is up to user choice. You can enable it right now if you want but this isn't what this ticket is about. I don't know what's your point there?

BTW: This BFQ bug was perhaps fixed long time ago.

EDIT:
To clarify: BLK-MQ is an interface and all drivers are being rewritten to use it (or already are). It doesn't matter if particular hardware supports multi queue or not - this will be handled internally by kernel. The old interface and its schedulers like cfq,deadline,noop are being phased out and will be removed in future. Arch can choose to enable it right now or be forced to use it later.

One question: Did you already test the feature yourself?
Adding scsi_mod.use_blk_mq=y as kernel boot parameter enables it, regardless of Arch kernel config.

Is it mature enough to really rely upon for daily use and avoid being a guinea pig?

I also noticed in the development cycle of kernel 4.19, that CONFIG_SCSI_MQ_DEFAULT defaulted to yes.
I thought that I would carry out a few test weeks for myself and wait until at least 4.19.{3,4} is available until requesting that we follow suit and enable it by default in our kernel.

Don't get me wrong, I am aware of the benefits, somehow I miss "playing it safe". Guess it's just me.

Yes, I tested it for a long time. Generally kernel maintainers are very conservative about default options. This one was introduced in Linux 3.18, 4 years ago. I don't think that waiting couple of weeks will change anything.

This is also what Clear Linux uses: https://github.com/clearlinux-pkgs/linux/blob/master/config-fragment#L342

https://lwn.net/Articles/767987/
You would not include an upgrade message that users are expected to set the appropriate ioscheduler by udev rules and that ionice will no longer work?
Edit:
I would wait for linux-lts to switch to 4.19, linux/linux-hardened/linux-zen to be 4.20/5.0 and switch all kernels at once to avoid udev rule issues between lts and other kernels.

@loqs

I don't understand what are you posting here. Users wouldn't be expected to do anything. If someone want to change schedulers with udev - they can, but this has nothing to do with default kernel config. Again - you posted link about BFQ scheduler which isn't the default for BLK-MQ thus isn't relevant for this ticket. Could you clarify your point here?

@your_doomsday please read back to my first post
"This would also switch the default scheduler from cfq to mq-deadline for devices that do not by default use the MQ schedulers."
The link I provided summarizes a discussion between kernel developers on the default scheduler for that case and the negative performance impact on slower devices.
You did read the patch in the link I posted? Can you point to any developer in the discussion arguing that mq-deadline is the appropriate default for such devices?
Why is a result produced by the proposed change not relevant?

"This would also switch the default scheduler from cfq to mq-deadline for devices that do not by default use the MQ schedulers."

Yes, this is the whole point of this change. Nothing more or less than this.

"You did read the patch in the link I posted?"

Which patch? The discussion you linked is about using BFQ instead of mq-deadline for some devices which I repeated several times already, isn't relevant for this ticket. The truth is that BFQ isn't ready yet.

"Can you point to any developer in the discussion arguing that mq-deadline is the appropriate default for such devices?"

If kernel developers set blk-mq as default option then it's obvious they think it's best choice for general use, why would they do this otherwise? Maybe some devices will be slower, others will be faster but in average the results will be better. This is what the default is for. You can argue about using BFQ, kyber or whatever for specific devices but this is what udev rules are for.

Sticking with cfq as default is also a choice. Did you saw kernel developer recommending cfq? No, nobody recommends it. That's why they're moving away from it.

No cfq is not an option for a multiqueue default. The switch only covers devices using scsi_mod the default MQ schedulers do not.
NVME devices use the none MQ or mq-deadline MQ this change would not affect that.
See https://github.com/zen-kernel/zen-kernel/commit/05d2f46ed42ca12307b9c792e00d02e14e87d2d1#diff-770586e82a162dbd2b70f2d5d926bac4 for BFQ not being ready there is also no mention
in the thread I linked by any kernel developer that they consider BFQ not ready. You are arguing that BFQ is not ready after 7 kernel releases and yet is still included?
You have not responded to the following points:
Waiting until 4.20 to synchronize with switching linux-lts.
Adding a message on update that the user is now expected to manually configure the ioscheduler via udev rules.
That ionice and its related syscall will no longer work. This can be replaced by cgroup use but if the user is aware of the need or the source code has been altered.

Please also provide use cases where you have found or believe there will be a performance benefit from this change.
Why not add the proposed patch I linked that was rejected upstream. Arch already carries such a patch in https://git.archlinux.org/linux.git/commit/?h=v4.19-arch1&id=ffc883bc93c2fed977fc82cc36305880fab10247
Alternatively why not add a udev rule switching the default scheduler for USB/memory cards/rotational devices to the linux package leaving only SSD devices on mq-deadline?

"No cfq is not an option for a multiqueue default"

Yes, with this change we're getting rid of cfq as "default" option.

"See ... for BFQ not being ready there is also no mention in the thread I linked by any kernel developer that they consider BFQ not ready. You are arguing that BFQ is not ready after 7 kernel releases and yet is still included?"

Linux-zen is a kernel fork which used BFQ years before it was even submitted in mainline, why is this relevant for this ticket? In discussion you linked kernel developers rejected using BFQ as default option instead of mq-deadline - this is a fact and that's why I said it's not ready yet. How one can argue at the same time in favour for BFQ and against blk-mq which was in kernel for 20 releases and kernel developers are setting it as default kconfig option?

"Waiting until 4.20 to synchronize with switching linux-lts."

Why? linux-lts doesn't synchronise config with linux - there were plenty of options introduced recently in linux like enabling selinux/apparmor and signing modules which aren't in linux-lts. They have even different maintainers. I don't see the reason why this one is different.

"Adding a message on update that the user is now expected to manually configure the ioscheduler via udev rules."

The user isn't expected to do anything. Most users won't be even aware that anything changed as this isn't "visible change" for them. For years I was switching between kernels with blk-mq enabled and disabled and using ssd/hdd/nvme/usb/sd and I wouldn't tell the difference unless I run some benchmarks.

"Please also provide use cases where you have found or believe there will be a performance benefit from this change."

SSD disks should be faster on blk-mq than on cfq.

"Why not add the proposed patch I linked that was rejected upstream. Arch already carries such a patch in ..."

The USER_NS patch has no alternative in local configuration - without it Arch would have USER_NS disabled completely. It was rejected by upstream for mostly political reasons. The (bfq?) patch can be easily replicated with udev rule. It also was rejected (for now) as not being ready. It may be accepted in future when BFQ is improved. Again - arguing in favour of BFQ and against of blk-mq is beyond me.

"Alternatively why not add a udev rule switching the default scheduler for USB/memory cards/rotational devices to the linux package leaving only SSD devices on mq-deadline?"

I don't think udev rules should be part of kernel package. I don't think Arch is the distro which should put opinionated (the system will function just fine without them) udev rules on user system. This should be part of local config and users choice.

If someone still have any doubts then please look at what is planned for 4.21:

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-4.21/block&id=f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-4.21/block&id=f382fb0bcef4c37dc049e9f6963e3baf204d815c

Single queue schedulers are dead.