Re: [PATCH v2] block: BFQ default for single queue devices

Oleksandr Natalenko
2018-11-02T10:40:42Z

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)