[Bug 1134353] adopting BFQ to control I/O
![](https://seccdn.libravatar.org/avatar/3035b38ff33cf86f480bb169b8500b80.jpg?s=120&d=mm&r=g)
http://bugzilla.suse.com/show_bug.cgi?id=1134353
http://bugzilla.suse.com/show_bug.cgi?id=1134353#c25
--- Comment #25 from Paolo Valente
Created attachment 809495 [details] comparison generated for io-fio-randread-[a]sync-{seq,rand}write mmtests results
Those looked odd and I double checked that they were reproducible. I didn't find flaws in the test setup thus I now report them. Maybe there is still some issue with the test -- results for (4) look quite odd -- so better try to reproduce yourself. Tests were done with kernel 5.2.0-rc3 using ext4 and "mitigations=off".
To summarize: (1) io-fio-randread-async-randwrite-ext4-nosecure Seems somehow ok. Higher write throughput allowed by lower read throughput (bfq vs. mq-deadline). (2) io-fio-randread-sync-heavywrite-ext4-nosecure Dito but kyber further reduces write throughput with much more gain for reads. (3) io-fio-randread-async-seqwrite-ext4-nosecure writes -(7..8%) reads +>2000% for other sched options in comparison to BFQ (4) io-fio-randread-sync-randwrite-ext4-nosecure Results are "off the charts". Both latencies (read and write) for BFQ are much worse than all other sched options resulting in much lower throughput for both reads and writes.
Based on that only mq-deadline and none deliver kind of not-surprising performance. The low read throughput of mere 48.64 KiB for io-fio-randread-async-seqwrite-ext4-nosecure with BFQ looks disturbing.
Thank you very much for these new tests. In the next weeks, I'll look for the cause of these anomalies, then I'll get back to your dbench results. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com