From: Linus Walleij <linus.walleij@linaro.org>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Mark Brown <broonie@kernel.org>,
Christoph Hellwig <hch@infradead.org>, Tejun Heo <tj@kernel.org>,
Jens Axboe <axboe@kernel.dk>,
Paolo Valente <paolo.valente@linaro.org>,
linux-block@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Omar Sandoval <osandov@fb.com>
Subject: Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ
Date: Thu, 8 Sep 2016 13:51:12 +0200 [thread overview]
Message-ID: <CACRpkdbU72KdBdRnNEFFBovrdGWsrNaPf-uYgxDXwCNmD33b4w@mail.gmail.com> (raw)
In-Reply-To: <17539224.xnQ9OR2lcz@amdc1976>
On Mon, Sep 5, 2016 at 5:56 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> I did this (switched MMC to blk-mq) some time ago. Patches are
> extremely ugly and hacky (basically the whole MMC block layer
> glue code needs to be re-done) so I'm rather reluctant to
> sharing them yet (to be honest I would like to rewrite them
> completely before posting).
You're right, I can also see the quick and dirty replacement path,
but that is not an honest patch, we need to make a patch that takes
advantage of the new features of the MQ tag set.
There is a bit of mechanisms in mq for handling parallell work
better so that e.g. the request stacking with calling out to
.pre_req() and .post_req() need to be done
differently and sglist handling can be simplified AFAICT (still
reading up on it).
> I only did linear read tests (using dd) so far and results that
> I got were mixed (BTW the hardware I'm doing this work on is
> Odroid-XU3). Pure block performance under maximum CPU frequency
> was slightly worse (5-12%) but the CPU consumption was reduced so
> when CPU was scaled down manually (or ondemand CPUfreq governor
> was used) blk-mq mode results were better then vanilla ones (up
> to 10% when CPU was scaled down to minimum frequency and even
> up to 50% when using ondemand governor - this finding is very
> interesting and needs to be investigated further).
Hm right, it is important to keep in mind that we may be trading
performance for scalability here.
Naive storage development only care about performance to hitting
the media and it may be a bit of narrow usecase to just get a
figure on the paper. In reality the system load when doing this
matters.
Yours,
Linus Walleij
next prev parent reply other threads:[~2016-09-08 11:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 11:14 [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ Paolo Valente
2016-08-08 11:14 ` [PATCH V2 01/22] block, cfq: remove queue merging for close cooperators Paolo Valente
2016-08-08 11:14 ` [PATCH V2 02/22] block, cfq: remove close-based preemption Paolo Valente
2016-08-08 11:14 ` [PATCH V2 03/22] block, cfq: remove deep seek queues logic Paolo Valente
2016-08-08 11:14 ` [PATCH V2 04/22] block, cfq: remove SSD-related logic Paolo Valente
2016-08-08 11:15 ` [PATCH V2 05/22] block, cfq: get rid of hierarchical support Paolo Valente
2016-08-08 11:15 ` [PATCH V2 06/22] block, cfq: get rid of queue preemption Paolo Valente
2016-08-08 11:15 ` [PATCH V2 07/22] block, cfq: get rid of workload type Paolo Valente
2016-08-08 11:15 ` [PATCH V2 08/22] block, cfq: get rid of latency tunables Paolo Valente
2016-08-08 11:15 ` [PATCH V2 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler Paolo Valente
2016-08-08 11:15 ` [PATCH V2 10/22] block, bfq: add full hierarchical scheduling and cgroups support Paolo Valente
2016-08-08 11:15 ` [PATCH V2 11/22] block, bfq: improve throughput boosting Paolo Valente
2016-08-08 11:15 ` [PATCH V2 12/22] block, bfq: modify the peak-rate estimator Paolo Valente
2016-08-08 11:15 ` [PATCH V2 13/22] block, bfq: add more fairness with writes and slow processes Paolo Valente
2016-08-08 11:15 ` [PATCH V2 14/22] block, bfq: improve responsiveness Paolo Valente
2016-08-08 11:15 ` [PATCH V2 15/22] block, bfq: reduce I/O latency for soft real-time applications Paolo Valente
2016-08-08 11:15 ` [PATCH V2 16/22] block, bfq: preserve a low latency also with NCQ-capable drives Paolo Valente
2016-08-08 11:15 ` [PATCH V2 17/22] block, bfq: reduce latency during request-pool saturation Paolo Valente
2016-08-08 11:15 ` [PATCH V2 18/22] block, bfq: add Early Queue Merge (EQM) Paolo Valente
2016-08-08 11:15 ` [PATCH V2 19/22] block, bfq: reduce idling only in symmetric scenarios Paolo Valente
2016-08-08 11:15 ` [PATCH V2 20/22] block, bfq: boost the throughput on NCQ-capable flash-based devices Paolo Valente
2016-08-08 11:15 ` [PATCH V2 21/22] block, bfq: boost the throughput with random I/O on NCQ-capable HDDs Paolo Valente
2016-08-08 11:15 ` [PATCH V2 22/22] block, bfq: handle bursts of queue activations Paolo Valente
2016-08-08 13:19 ` [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ Christoph Hellwig
2016-08-08 13:37 ` Paolo
2016-08-31 22:09 ` Mark Brown
2016-09-01 8:39 ` Linus Walleij
2016-09-05 15:56 ` Bartlomiej Zolnierkiewicz
2016-09-05 20:29 ` Paolo Valente
2016-09-08 11:51 ` Linus Walleij [this message]
2016-09-01 21:06 ` Eric Wheeler
2016-09-08 12:11 ` Hannes Reinecke
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=CACRpkdbU72KdBdRnNEFFBovrdGWsrNaPf-uYgxDXwCNmD33b4w@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=axboe@kernel.dk \
--cc=b.zolnierkie@samsung.com \
--cc=broonie@kernel.org \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=osandov@fb.com \
--cc=paolo.valente@linaro.org \
--cc=tj@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).