Mailinglist Archive: opensuse-bugs (6499 mails)

< Previous Next >
[Bug 1134353] adopting BFQ to control I/O
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Sat, 06 Jul 2019 05:57:22 +0000
  • Message-id: <>

--- Comment #25 from Paolo Valente <paolo.valente@xxxxxxxxxx> ---
(In reply to Andreas Herrmann from comment #24)
Created attachment 809495 [details]
comparison generated for io-fio-randread-[a]sync-{seq,rand}write mmtests

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

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

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.
< Previous Next >