From: Arnd Bergmann <arnd@arndb.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Paolo Valente <paolo.valente@linaro.org>,
Christoph Hellwig <hch@infradead.org>,
Bart Van Assche <bart.vanassche@sandisk.com>,
Jan Kara <jack@suse.cz>, Tejun Heo <tj@kernel.org>,
linux-block@vger.kernel.org,
Linux-Kernal <linux-kernel@vger.kernel.org>,
Mark Brown <broonie@kernel.org>, Hannes Reinecke <hare@suse.de>,
Grant Likely <grant.likely@secretlab.ca>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler
Date: Fri, 28 Oct 2016 18:05:35 +0200 [thread overview]
Message-ID: <2423164.8ioLhGisxr@wuerfel> (raw)
In-Reply-To: <3d0b38bb-537d-94ff-574f-587bad949fdd@kernel.dk>
On Friday, October 28, 2016 9:30:07 AM CEST Jens Axboe wrote:
> On 10/28/2016 03:32 AM, Linus Walleij wrote:
> > The patch to enable MQ looks like this:
> > https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=mmc-mq&id=8f79b527e2e854071d8da019451da68d4753f71d
>
> BTW, another viable "hack" for the depth issue would be to expose more
> than one hardware queue. It's meant to map to a distinct submission
> region in the hardware, but there's nothing stopping the driver from
> using it differently. Might not be cleaner than just increasing the
> queue depth on a single queue, though.
>
> That still won't solve the issue of lying about it and causing IO
> scheduler confusion, of course.
>
> Also, 4.8 and newer have support for BLK_MQ_F_BLOCKING, if you need to
> block in ->queue_rq(). That could eliminate the need to offload to a
> kthread manually.
I think the main reason for the kthread is that on ARM and other
architectures, the dma mapping operations are fairly slow (for
cache flushes or bounce buffering) and we want to minimize the
time between subsequent requests being handled by the hardware.
This is not unique to MMC in any way, MMC just happens to be
common on ARM and it is limited by its lack of hardware
command queuing.
It would be nice to do a similar trick for SCSI disks,
especially USB mass storage, maybe also SATA, which are the
next most common storage devices on non-coherent ARM systems
(SATA nowadays often comes with NCQ, so it's less of an
issue)
It may be reasonable to tie this in with the I/O scheduler:
if you don't have a scheduler, the access to the device is
probably rather direct and you want to avoid any complexity
in the kernel, but if preparing a request is expensive
and the hardware has no queuing, you probably also want to
use a scheduler.
We should probably also try to understand how this could
work out with USB mass storage, if there is a solution at
all, and then do it for MMC in a way that would work on
both. I don't think the USB core can currently split the
dma_map_sg() operation from the USB command submission,
so this may require some deeper surgery there.
Arnd
next prev parent reply other threads:[~2016-10-28 16:06 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 9:27 [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Paolo Valente
2016-10-26 9:27 ` [PATCH 01/14] block, bfq: " Paolo Valente
2016-10-26 9:27 ` [PATCH 02/14] block, bfq: add full hierarchical scheduling and cgroups support Paolo Valente
2016-10-26 9:27 ` [PATCH 03/14] block, bfq: improve throughput boosting Paolo Valente
2016-10-26 9:27 ` [PATCH 04/14] block, bfq: modify the peak-rate estimator Paolo Valente
2016-10-26 9:27 ` [PATCH 05/14] block, bfq: add more fairness with writes and slow processes Paolo Valente
2016-10-26 9:27 ` [PATCH 06/14] block, bfq: improve responsiveness Paolo Valente
2016-10-26 9:28 ` [PATCH 07/14] block, bfq: reduce I/O latency for soft real-time applications Paolo Valente
2016-10-26 9:28 ` [PATCH 08/14] block, bfq: preserve a low latency also with NCQ-capable drives Paolo Valente
2016-10-26 9:28 ` [PATCH 09/14] block, bfq: reduce latency during request-pool saturation Paolo Valente
2016-10-26 10:19 ` [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Christoph Hellwig
2016-10-26 11:34 ` Jan Kara
2016-10-26 15:05 ` Bart Van Assche
2016-10-26 15:13 ` Arnd Bergmann
2016-10-26 15:29 ` Christoph Hellwig
2016-10-26 15:32 ` Jens Axboe
2016-10-26 16:04 ` Paolo Valente
2016-10-26 16:12 ` Jens Axboe
2016-10-27 9:26 ` Jan Kara
2016-10-27 14:34 ` Grozdan
2016-10-27 15:55 ` Heinz Diehl
2016-10-27 16:28 ` Jens Axboe
2016-10-27 16:26 ` Jens Axboe
2016-10-28 7:59 ` Jan Kara
2016-10-28 14:10 ` Jens Axboe
2016-10-27 17:32 ` Ulf Hansson
2016-10-27 17:43 ` Jens Axboe
2016-10-27 18:13 ` Ulf Hansson
2016-10-27 18:21 ` Jens Axboe
2016-10-27 19:34 ` Ulf Hansson
2016-10-27 21:08 ` Jens Axboe
2016-10-27 22:27 ` Linus Walleij
2016-10-28 9:32 ` Linus Walleij
2016-10-28 14:22 ` Jens Axboe
2016-10-28 20:38 ` Linus Walleij
2016-10-28 15:29 ` Christoph Hellwig
2016-10-28 21:09 ` Linus Walleij
2016-10-28 15:30 ` Jens Axboe
2016-10-28 15:58 ` Bartlomiej Zolnierkiewicz
2016-10-28 16:05 ` Arnd Bergmann [this message]
2016-10-28 17:17 ` Mark Brown
2016-10-28 14:07 ` Jens Axboe
2016-10-28 6:36 ` Ulf Hansson
2016-10-28 14:17 ` Jens Axboe
2016-10-28 17:12 ` Mark Brown
2016-10-27 19:41 ` Mark Brown
2016-10-27 19:45 ` Christoph Hellwig
2016-10-27 22:01 ` Mark Brown
2016-10-28 12:07 ` Arnd Bergmann
2016-10-28 12:17 ` Richard Weinberger
2016-10-29 5:38 ` Paolo Valente
2016-10-29 13:12 ` Bart Van Assche
2016-10-29 14:12 ` Jens Axboe
2016-10-30 3:06 ` Paolo Valente
2016-10-26 12:37 ` Paolo Valente
-- strict thread matches above, loose matches on Subject: below --
2016-10-29 17:08 Manuel Krause
2016-10-30 17:48 Manuel Krause
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=2423164.8ioLhGisxr@wuerfel \
--to=arnd@arndb.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=axboe@kernel.dk \
--cc=b.zolnierkie@samsung.com \
--cc=bart.vanassche@sandisk.com \
--cc=broonie@kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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