linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>,
	Paolo Valente <paolo.valente@linaro.org>,
	Jens Axboe <axboe@kernel.dk>, Tejun Heo <tj@kernel.org>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	ulf.hansson@linaro.org, linus.walleij@linaro.org,
	broonie@kernel.org, hare@suse.de, grant.likely@secretlab.ca,
	James.Bottomley@hansenpartnership.com
Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler
Date: Wed, 26 Oct 2016 17:13:07 +0200	[thread overview]
Message-ID: <12386463.fJy0cVexVD@wuerfel> (raw)
In-Reply-To: <4ed3e291-b3e5-5ee3-6838-58644bd3d99b@sandisk.com>

On Wednesday, October 26, 2016 8:05:11 AM CEST Bart Van Assche wrote:
> On 10/26/2016 04:34 AM, Jan Kara wrote:
> > On Wed 26-10-16 03:19:03, Christoph Hellwig wrote:
> >> Just as last time:
> >>
> >> big NAK for introducing giant new infrastructure like a new I/O scheduler
> >> for the legacy request structure.
> >>
> >> Please direct your engergy towards blk-mq instead.
> >
> > Christoph, we will probably talk about this next week but IMO rotating
> > disks and SATA based SSDs are going to stay with us for another 15 years,
> > likely more. For them blk-mq is no win, relatively complex IO scheduling
> > like CFQ or BFQ does is a big win for them in some cases. So I think IO
> > scheduling (and thus place for something like BFQ) is going to stay with us
> > for quite a long time still. So are we going to add hooks in blk-mq to
> > support full-blown IO scheduling at least for single queue devices? Or how
> > else do we want to support that HW?
> 
> Hello Jan,
> 
> Having two versions (one for non-blk-mq, one for blk-mq) of every I/O 
> scheduler would be a maintenance nightmare. Has anyone already analyzed 
> whether it would be possible to come up with an API for I/O schedulers 
> that makes it possible to use the same I/O scheduler for both blk-mq and 
> the traditional block layer?

The question to ask first is whether to actually have pluggable
schedulers on blk-mq at all, or just have one that is meant to
do the right thing in every case (and possibly can be bypassed
completely).

	Arnd

  reply	other threads:[~2016-10-26 15:13 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 [this message]
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
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
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=12386463.fJy0cVexVD@wuerfel \
    --to=arnd@arndb.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=axboe@kernel.dk \
    --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;
as well as URLs for NNTP newsgroup(s).