Hi.
On 16.10.2018 19:35, Jens Axboe wrote:
Do you have anything more recent? All of these predate the current
code (by a lot), and isn't even mq. I'm mostly just interested in
plain fast NVMe device, and a big box hardware raid setup with
a ton of drives.
I do still think that this should be going through the distros, they
need to be the ones driving this, as they will ultimately be the
ones getting customer reports on regressions. The qual/test cycle
they do is useful for this. In mainline, if we make a change like
this, we'll figure out if it worked many releases down the line.
Some benchmarks here for a non-RAID setup obtained by S suite. This is
from Lenovo T460s with SAMSUNG MZNTY256HDHP-000L7 SSD. v4.19 kernel is
running with all recent BFQ patches applied.
# replayed gnome terminal startup throughput
# Workload bfq mq-deadline
0r-raw_seq 13.2617 13.4867
10r-raw_seq 512.507 539.95
# replayed gnome terminal startup time
# Workload bfq mq-deadline
0r-raw_seq 0.43 0.4
10r-raw_seq 0.685 4.1625
# replayed lowriter startup throughput
# Workload bfq mq-deadline
0r-raw_seq 9.985 10.375
10r-raw_seq 516.62 539.61
# replayed lowriter startup time
# Workload bfq mq-deadline
0r-raw_seq 0.4 0.3875
10r-raw_seq 0.535 2.3875
# replayed xterm startup throughput
# Workload bfq mq-deadline
0r-raw_seq 5.93833 6.10834
10r-raw_seq 524.447 539.991
# replayed xterm startup time
# Workload bfq mq-deadline
0r-raw_seq 0.23 0.23
10r-raw_seq 0.38 1.56
# throughput
# Workload bfq mq-deadline
10r-raw_rand 362.446 363.817
10r-raw_seq 537.646 540.609
1r-raw_seq 500.733 502.526
Throughput-wise, BFQ is on-par with mq-deadline. Latency-wise, BFQ is
much-much better.
--
Oleksandr Natalenko (post-factum)
