http://bugzilla.suse.com/show_bug.cgi?id=1134353 http://bugzilla.suse.com/show_bug.cgi?id=1134353#c37 --- Comment #37 from Andreas Herrmann <aherrmann@suse.com> --- Of the different workloads that supposedly showed lower performance with BFQ most stuff was sorted out and in the end we had dbench and some of our fio tests. I think the dbench thing wasn't fully tracked down. But probably more important is the info gathered from the fio tests -- see comment #31 and comment #33. In short, I think BFQ is the only blk-mq scheduler providing means to really control I/O: (1) This is shown with S-startup tests, where BFQ uses different weights for interactive processes which substantially boosts startup times of various applications. This even can be seen when you run one of our fio tests on your laptop in the background and try to launch a new terminal instance, or gimp etc. With mq-deadline startup time is substantially increased (the delay is quite noticeable) and only with bfq you notice no difference to when no fio background workload is running. (2) As mentioned in comment #33 BFQ allows usage of ionice to really guarantee higher priority for certain workloads (e.g. reads in the fio tests shown in attachment #819989). I am not aware that ionice can be used with other blk-mq scheduler options. (At least with mq-deadline it does not work.) (3) BFQ also provides cgroup support which allows to set finer grained weights (in comparison to using ionice) for certain workloads. (I've also successfully verified that this is working as expected.) So for recent kernels (after the removal of legacy block and CFQ) I think BFQ is the only scheduler option that allows to reasonably control I/O. Thus a valid question is: Should BFQ be used as default scheduler option not only for rotary devices but also for SSDs (single queue) in OpenSUSE?
From my recent tests I think this would make sense.
-- You are receiving this mail because: You are on the CC list for the bug.