Linux 4.15 I/O Scheduler Tests: BFQ, CFQ, Kyber

[phoronix]

Phoronix: Linux 4.15 I/O Scheduler Tests: BFQ, CFQ, Kyber

With some BFQ performance fixes included as part of Linux 4.15 along with other I/O scheduler work and block improvements for this latest Linux kernel series, here are some fresh benchmarks of the different I/O scheduler options using the Linux 4.15 Git kernel.

http://www.phoronix.com/vr.php?view=25646

[Charlie68]

In openSUSE you can set the value from Yast, I on the notebook with ssd I set Noop, while on the desktop with HD I set cfq.

[geearf]

What's BFQ low_latency supposed to be? The low_latency tunable is enabled by default, what else is there?

[RealNC]

Isn't BFQ supposed to prefer interactivity (avoiding UI freezes and such) instead of performance?

[geearf]

Isn't BFQ supposed to prefer interactivity (avoiding UI freezes and such) instead of performance?

It is indeed, hence the tests about startup time under load.

[Licaon]

In openSUSE you can set the value from Yast, I on the notebook with ssd I set Noop, while on the desktop with HD I set cfq.

CFQ is SSD aware for years already, stop using NOOP just because "it sounds better"

[Charlie68]

Does it sound better?

https://doc.opensuse.org/documentation/leap/tuning/html/book.sle.tuning/cha.tuning.io.html

[Jumbotron]

Where and how can you check what scheduler you're using? And then how can you change that if you wanted to ?

[Slithery]

cat /sys/block/sdX/queue/scheduler
echo <SCHEDULER> > /sys/block/sdX/queue/scheduler

You can change the scheduler permanently by using

elevator=<SCHEDULER>

in your kernel parameters.

[ⲣⲂaggins]

I'm leaving BFQ disabled for now after what happened with kernel 4.12 when it was first enabled. After a suspend/resume cycle the system would become unusable due to all io related syscalls hanging. It turned out nobody had tested how the new code interacted with suspend/resume, despite the fact that the power-management features implemented at the time were known to be stubbed out. I believe this was fixed in 4.14, but it does not instil in me great faith that the kernel devs can prevent potentially filesystem-corrupting bugs from slipping through the net in the future.