Should Ubuntu Use The BFQ I/O Scheduler?

[Vistaus]

Does porn load quicker?

Does XKCD load quicker? #truenerdquestion

[starshipeleven]

Oh, I was not aware of this. I am not up-to-date. It's been a few years since I've read about the I/O schedulers.

$ cat /sys/block/sdb/queue/scheduler
[mq-deadline] none

I guess I am on the "mq-deadline" scheduler, but I don't know what that is.

Newer schedules are all multi-queue, i.e. they have more than 1 queue depending on the hardware capacity.

"mq-deadline" is the multi-queue version of deadline.

"none" means "no scheduling at all", still multi-queue.

Other schedulers available in sane distros are Kyber (from Facebook) and BFQ, again all multi-queue.

[varikonniemi]

It most certainly should. It is unacceptable that things start lagging just because you copy a file. Especially since the newest iteration of bfq has almost no throughput penalty there are really no arguments against it being default.

[carewolf]

Just enabled it this morning after reading this article, and been using it through the day. Can't say I am impressed. It deals extremely poorly with the background distributed compiler jobs we have in the office, so every time a job comes the IDE stops responding for a second or two, even though the background jobs are niced 15 and started by a background daemon as background tasks.

At least for my use-case BFQ does the exact opposite of providing a more responsive desktop experience, and instead prioritized highly niced background jobs over currently used active desktop jobs.

I guess I should have stayed with CFQ since that was working perfectly.. Oh, how many times must I learn not fix things that are not broken.

[S.Pam]

Does porn load quicker?

It will stutter less

[S.Pam]

Just enabled it this morning after reading this article, and been using it through the day. Can't say I am impressed. It deals extremely poorly with the background distributed compiler jobs we have in the office, so every time a job comes the IDE stops responding for a second or two, even though the background jobs are niced 15 and started by a background daemon as background tasks.

At least for my use-case BFQ does the exact opposite of providing a more responsive desktop experience, and instead prioritized highly niced background jobs over currently used active desktop jobs.

I guess I should have stayed with CFQ since that was working perfectly.. Oh, how many times must I learn not fix things that are not broken.

BFQ uses cgroups (io.bfq.weight) for io niceness. This is what you should look at, or at least use "ionice" and not the "nice" tool.

[carewolf]

BFQ uses cgroups (io.bfq.weight) for io niceness. This is what you should look at, or at least use "ionice" and not the "nice" tool.

But normally ionice is inherited from nice automatically (basically nice/2).

For kernels after 2.6.26 with the CFQ I/O scheduler, a process that has not asked for an I/O priority inherits its CPU scheduling class.

Aha.. So, automatically setting ionice levels from nice levels a CFQ feature :/

A rather nice one though.

[Space Heater]

I guess I should have stayed with CFQ since that was working perfectly.. Oh, how many times must I learn not fix things that are not broken.

How were you using CFQ if you switched to BFQ? CFQ doesn't exist anymore, once blk-mq became the default around the 4.20 release, the single queue block schedulers were removed.

[tildearrow]

Is BFQ better than NOOP or Deadline on SSDs?

Can somebody ever care about HDD?

[carewolf]

How were you using CFQ if you switched to BFQ? CFQ doesn't exist anymore, once blk-mq became the default around the 4.20 release, the single queue block schedulers were removed.

blk-mq was not on by default for me, to even use BFQ, I had to first enable blk-mq on the kernel command-line, update grub and reboot. Debian probably changed the default to off for blk-mq.