On Tue, Jan 31, 2023 at 2:20 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, Jan 31, 2023 at 10:57:38AM +0100, Linus Walleij wrote: > > Now it doesn't require it, it will just perform better, so thus I use > > > > imply IOSCHED_BFQ > > > > the point with it is to help users make the right decisions, not > > enforce them. fs/crypto/Kconfig does the same thing for example, > > advice not enforce. > > I'd really love to see how it always works better, as none of that > has actually been documented. I guess I would need to turn that around and ask what kind of documentation would convince you? I guess this isn't enough: https://www.kernel.org/doc/html/latest/block/bfq-iosched.html To be clear, "works better" in this context means, solving a problem for the interactive user, preventing random freezing of the UI on resource-limited (memory, disk throughput) systems under high I/O load. Not maximizing throughput in general, which is the common misunderstanding. I personally ran into it, and blogged about it: https://people.kernel.org/linusw/bfq-saved-me-from-thrashing The phenomenon of freezing UI also happens on e.g. Android while updating the apps in the background as illustrated by Paolo here: https://www.youtube.com/watch?v=ANfqNiJVoVE More demos on more devices (mostly MMC/SD): https://www.youtube.com/user/valentepaolo/videos He also has several practical measurements of it and a test suite: http://algogroup.unimore.it/people/paolo/disk_sched/results.php There are also peer-reviewed IEEE articles and what not. > And given the wide variety of hardware > and workloads I also very much doubt it. The problem it solves appears on slow single-queue devices where the scheduler cannot distinguish importance between processes and treat all processes the same. It does not try to solve the problem of maximizing throughput on a real fast MQ device. For MMC/SD-based systems this is very real, and that is why this is implied by a patch to the MMC/SD subsystem. Embedded interactive devices use MMC/SD-cards, while enterprise storage systems does not. This is why the udev rule in RedHat/Fedora looks like this: 60-block-scheduler.rules ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", \ KERNEL=="mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|sd*[!0-9]|sr*", \ ATTR{queue/scheduler}="bfq" Targetting most slow single-queue devices with BFQ. SuSE has something similar: https://github.com/openSUSE/udev-extra-rules/blob/master/60-io-scheduler.rules Yours, Linus Walleij
