From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: Jens Axboe <axboe@kernel.dk>
Cc: Paolo Valente <paolo.valente@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
linux-block <linux-block@vger.kernel.org>,
linux-mmc <linux-mmc@vger.kernel.org>,
linux-mtd@lists.infradead.org, Pavel Machek <pavel@ucw.cz>,
Ulf Hansson <ulf.hansson@linaro.org>,
Richard Weinberger <richard@nod.at>,
Adrian Hunter <adrian.hunter@intel.com>,
Bart Van Assche <bvanassche@acm.org>, Jan Kara <jack@suse.cz>,
Artem Bityutskiy <dedekind1@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Mark Brown <broonie@kernel.org>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v2] block: BFQ default for single queue devices
Date: Fri, 02 Nov 2018 11:40:42 +0100 [thread overview]
Message-ID: <7fff1835bc9a0a95686db27d524e6818@natalenko.name> (raw)
In-Reply-To: <7375c004-ac6e-c692-4282-46de554285d5@kernel.dk>
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)
next prev parent reply other threads:[~2018-11-02 10:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 14:10 [PATCH v2] block: BFQ default for single queue devices Linus Walleij
2018-10-15 14:22 ` Paolo Valente
2018-10-15 14:32 ` Oleksandr Natalenko
2018-10-19 8:33 ` Linus Walleij
2018-10-19 9:26 ` Oleksandr Natalenko
2018-10-15 15:02 ` Bart Van Assche
2018-10-15 18:34 ` Paolo Valente
2018-10-17 5:18 ` Paolo Valente
2018-10-16 16:14 ` Federico Motta
2018-10-16 16:26 ` Paolo Valente
2018-10-15 15:39 ` Jens Axboe
2018-10-15 18:26 ` Paolo Valente
2018-10-15 19:26 ` Jens Axboe
2018-10-15 19:44 ` Paolo Valente
2018-10-16 17:35 ` Jens Axboe
2018-10-17 10:05 ` Jan Kara
2018-10-17 14:48 ` Bart Van Assche
2018-10-17 14:59 ` Bryan Gurney
2018-10-19 8:42 ` Linus Walleij
2018-10-19 13:36 ` Bryan Gurney
2018-10-19 13:44 ` Johannes Thumshirn
2018-10-19 14:16 ` Bryan Gurney
2018-10-22 8:12 ` Jens Axboe
2018-10-17 16:01 ` Mark Brown
2018-10-17 16:29 ` Jens Axboe
2018-10-18 7:21 ` Jan Kara
2018-10-18 14:35 ` Jens Axboe
2018-10-19 8:22 ` Pavel Machek
2018-10-22 8:08 ` Jens Axboe
2018-11-02 10:40 ` Oleksandr Natalenko [this message]
2018-10-19 10:59 ` Paolo Valente
2018-10-22 8:21 ` Jens Axboe
2018-10-16 13:42 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7fff1835bc9a0a95686db27d524e6818@natalenko.name \
--to=oleksandr@natalenko.name \
--cc=Damien.LeMoal@wdc.com \
--cc=adrian.hunter@intel.com \
--cc=axboe@kernel.dk \
--cc=broonie@kernel.org \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=dedekind1@gmail.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jthumshirn@suse.de \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paolo.valente@linaro.org \
--cc=pavel@ucw.cz \
--cc=richard@nod.at \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox