MuQSS Scheduler Updated, Linux 4.19-ck1 Drops BFQ I/O Scheduler

[phoronix]

Phoronix: MuQSS Scheduler Updated, Linux 4.19-ck1 Drops BFQ I/O Scheduler

Con Kolivas is out with an updated version of his MuQSS scheduler (based on his former Brain BFS Scheduler work) as well as his "-ck" patch-set against the mainline kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-ck1-MuQSS

[cl333r]

In Ubuntu 18.10 BFQ isn't even mentioned:
cat /sys/block/sda/queue/scheduler
outputs:
noop deadline [cfq]

[Vistaus]

In Ubuntu 18.10 BFQ isn't even mentioned:
cat /sys/block/sda/queue/scheduler
outputs:
noop deadline [cfq]

Even Kyber isn't mentioned :/ Strange. Here on Solus, they are mentioned. CFQ isn't, though (which I don't care about as I prefer Kyber or BFQ anyway).

cat /sys/block/sda/queue/scheduler
mq-deadline [kyber] bfq none

[Slithery]

...based on his former Brain BFS Scheduler work...

It's called either BFS or Brain Fuck Scheduler, I'm not quite sure what you're referring to

[perpetually high]

$ cat /sys/block/sda/queue/scheduler
[none] mq-deadline kyber bfq

I'm a none kind of guy myself

For a while I was trying out CK's MuQSS and Alfred Chen's PDS (based off CK's BFS) but ran into some instability (crashes found in /var/crash), and I wasn't contributing to bug reports so I just stopped using them.

Would be great to see some benchmarks comparing those two and the vanilla kernel, if you have free time.

if (Michael && freeTime) {
// we never get here
}

[tildearrow]

In Ubuntu 18.10 BFQ isn't even mentioned:
cat /sys/block/sda/queue/scheduler
outputs:
noop deadline [cfq]

Adding this to the kernel parameters (e.g. /etc/default/grub) will do:

scsi_mod.use_blk_mq=1

(UPDATE: this may be dangerous)

[hax0r]

Linux desktop users have been plagued with audio stutters and mouse cursor skipping issue for years, I easily run into this issue on just about any computer, all it takes is put 100% IO load on any storage device e.g. scard/usb flashdrive/external hdd by doing simple thing like copying a file and you just watch iowait number ramp up and experience totally unresponsive system. I can't recall what used be a decent kernel, it has been so long, but I remember 2.6.20~2.6.24 working well back in gcc 3.2 days. I'm really sad. Nobody really cares about this because kernel developers are paid by big companies and their target is CFS a systems with >= 1024 threads, that's were CFS performs well. Not only that, the kernel developers don't test for performance regressions outside their workload. Typical desktop users with quadcore cpus are left in dust.

[cl333r]

Adding this to the kernel parameters (e.g. /etc/default/grub) will do:

scsi_mod.use_blk_mq=1

Didn't work:

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=1"

[TemplarGR]

Linux desktop users have been plagued with audio stutters and mouse cursor skipping issue for years, I easily run into this issue on just about any computer, all it takes is put 100% IO load on any storage device e.g. scard/usb flashdrive/external hdd by doing simple thing like copying a file and you just watch iowait number ramp up and experience totally unresponsive system. I can't recall what used be a decent kernel, it has been so long, but I remember 2.6.20~2.6.24 working well back in gcc 3.2 days. I'm really sad. Nobody really cares about this because kernel developers are paid by big companies and their target is CFS a systems with >= 1024 threads, that's were CFS performs well. Not only that, the kernel developers don't test for performance regressions outside their workload. Typical desktop users with quadcore cpus are left in dust.

There are some kernel values you can alter to help with those issues:

https://wiki.archlinux.org/index.php/Swap#Swappiness

https://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

[aorth]

Important to note a comment from damentz (Zen kernel developer) on CK's blog post:

BFQ has only recently gotten, very good. If you've been running mainline, the final patches that make BFQ worthwhile probably just got merged in 4.19. Otherwise, if you've been running the Algodev/bfq-mq branch already, then BFQ has been behaving properly for a few months now.

Secondly, the legacy block subsystem caused a lot of problems that BFQ has no control over. The newer 'blk-mq' subsystem seems to reduce problems the legacy block incurred, letting BFQ do its thing.