Linux 4.9 I/O Scheduler Benchmarks On A SSD: Noop vs. CFQ vs. Deadline

[egaz]

Not quite. The push now from the I/O scheduler folks is how to keep throughput high while minimizing impact to responsiveness. BFQ typically wins this use-case, but wont beat CFQ for raw throughput, but then that isnt the point of BFQ.

blk-mq and BFQ are different things. There should be added for completness.

[FishPls]

I don't believe the 850 EVO was ever affected. Afaik it was only 840. And even if it were, wasn't it a kernel bug that was fixed shortly after discovery?

Here's the kernel fix https://www.spinics.net/lists/raid/msg49440.html

Actually looks like the Evo 850 was blacklisted too, but with the fix in place i think queued trim is safe to use?

[Kraut]

A lot of SSDs have queued trim blacklisted because it did not get used in windows. And for that reason a lot of implementation where broken. Like in "destroying all your data" broken!

[Zan Lynx]

I also remember that it turned out most SSD vendors were doing it right and the Linux kernel was performing a horrible, horrible bug with TRIM. And that it got fixed.

http://www.spinics.net/lists/raid/msg49440.html

[SaucyJack]

This benchmark isn't useful without BFQ.

[Rallos Zek]

Not quite. The push now from the I/O scheduler folks is how to keep throughput high while minimizing impact to responsiveness. BFQ typically wins this use-case, but wont beat CFQ for raw throughput, but then that isnt the point of BFQ.

BFQ is from looking at tests done and real world usage is snake oil. BFQ does not win any nor have any positive affect on desktop interactive responsiveness.

[milkylainen]

Interesting benchmarks.
But all I see are a screwed up I/O subsystem. I can't find a normal reason where CFQ would be faster than NO-OP on a non-rotational media with a single user/thread case. The whole point has to be to trade bandwidth for I/O latency. The same goes for CFQ. It looses so badly to NO-OP in another single user/thread case I have to wonder wth it's actually doing...

[cj.wijtmans]

Interesting benchmarks.
But all I see are a screwed up I/O subsystem. I can't find a normal reason where CFQ would be faster than NO-OP on a non-rotational media with a single user/thread case. The whole point has to be to trade bandwidth for I/O latency. The same goes for CFQ. It looses so badly to NO-OP in another single user/thread case I have to wonder wth it's actually doing...

A lot of context switching?

[jwh7]

BFQ is from looking at tests done and real world usage is snake oil. BFQ does not win any nor have any positive affect on desktop interactive responsiveness.

References? Have you ever used it, or even seen/read the tests done? That must be why many distributions use it by default, out-of-tree. Speaking of the latter, its been submitted to LKML today (and there are references):

https://lkml.org/lkml/2016/10/26/218

[sarfarazahmad]

References? Have you ever used it, or even seen/read the tests done? That must be why many distributions use it by default, out-of-tree. Speaking of the latter, its been submitted to LKML today (and there are references):
https://lkml.org/lkml/2016/10/26/218

thank you. the fact that its been submitted to mainline kernel was a pleasant way to start my day . I am a longtime user of BFQ and can confirm its validity. Its an amazing scheduler. High throughput high response times. In fact, it performs better than blk-mq for rotating media.