All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Block pull request for- 4.11-rc1
Date: Tue, 21 Feb 2017 16:15:53 -0700	[thread overview]
Message-ID: <ef431f1c-e3c6-4940-bb2a-f5131ca96855@kernel.dk> (raw)
In-Reply-To: <CA+55aFxr-jpdwViA1Y7AiP9WEh4Eutad0_XDnBH2BNtyGYPd5Q@mail.gmail.com>

On 02/21/2017 04:02 PM, Linus Torvalds wrote:
> Hmm. The new config options are incomprehensible and their help
> messages don't actually help.
> 
> So can you fill in the blanks on what
> 
>   Default single-queue blk-mq I/O scheduler
>   Default multi-queue blk-mq I/O scheduler
> 
> config options mean, and why they default to none?
> 
> The config phase of the kernel is one of the worst parts of the whole
> project, and adding these kinds of random and incomprehensible config
> options does *not* help.

I'll try and see if I can come up with some better sounding/reading
explanations.

But under a device managed by blk-mq, that device exposes a number of
hardware queues. For older style devices, that number is typically 1
(single queue). This is true for most SCSI devices that are run by
scsi-mq, which is often hosting rotational storage. Faster devices, like
nvme, exposes a lot more hardware queues (multi-queue). Hence the
distinction between having a scheduler attached for single-queue
devices, and for multi-queue devices. For rotational devices, we'll want
to default to something like mq-deadline, and I actually thought that
was the default already. It should be (see below). For multi-queue
devices, we'll want to initially default to "none", and then later
attach a properly multiqueue scheduler, when we have it (it's still in
development).

"none" just means that we don't have a scheduler attached.

In essence, we want to default to having a sane IO scheduler attached
depending on device class. For single-queue devices, that's deadline for
now. For multi-queue, we'll want to wait until we have something that
scales really well. It's not that easy to present this information in a
user grokkable fashion, since most people would not know the difference
between the two.

I'll send the below as a real patch, and also ponder how we can improve
the Kconfig text.

diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched
index 0715ce93daef..f6144c5d7c70 100644
--- a/block/Kconfig.iosched
+++ b/block/Kconfig.iosched
@@ -75,7 +75,7 @@ config MQ_IOSCHED_NONE
 
 choice
 	prompt "Default single-queue blk-mq I/O scheduler"
-	default DEFAULT_SQ_NONE
+	default DEFAULT_SQ_DEADLINE if MQ_IOSCHED_DEADLINE=y
 	help
 	  Select the I/O scheduler which will be used by default for blk-mq
 	  managed block devices with a single queue.

-- 
Jens Axboe

  reply	other threads:[~2017-02-21 23:15 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20  0:10 [GIT PULL] Block pull request for- 4.11-rc1 Jens Axboe
2017-02-20  1:09 ` Bart Van Assche
2017-02-20  1:09   ` Bart Van Assche
2017-02-20  1:15   ` Jens Axboe
2017-02-20  2:12     ` James Bottomley
2017-02-20  2:12       ` James Bottomley
2017-02-20  2:59       ` Jens Axboe
2017-02-20  3:02         ` Jens Axboe
2017-02-20  7:35     ` Christoph Hellwig
2017-02-20 16:16       ` Bart Van Assche
2017-02-20 16:16         ` Bart Van Assche
2017-02-20 16:32         ` Jens Axboe
2017-02-21  1:18           ` Bart Van Assche
2017-02-21  1:18             ` Bart Van Assche
2017-02-24 17:39           ` Bart Van Assche
2017-02-24 17:39             ` Bart Van Assche
2017-02-24 17:51             ` Jens Axboe
2017-02-24 19:43             ` Linus Torvalds
2017-02-24 20:00               ` Jens Axboe
2017-02-24 20:22                 ` Jens Axboe
2017-02-24 21:15                   ` Bart Van Assche
2017-02-24 21:15                     ` Bart Van Assche
2017-02-25 18:17                   ` hch
2017-02-25 18:22                     ` Jens Axboe
2017-02-21 19:11 ` Linus Torvalds
2017-02-21 19:34   ` Jens Axboe
2017-02-21 23:02   ` Linus Torvalds
2017-02-21 23:15     ` Jens Axboe [this message]
2017-02-21 23:23       ` Linus Torvalds
2017-02-22 18:14         ` Jens Axboe
2017-02-22 18:26           ` Linus Torvalds
2017-02-22 18:41             ` Jens Axboe
2017-02-22 18:45               ` Linus Torvalds
2017-02-22 18:52                 ` Jens Axboe
2017-02-22 18:56                   ` Linus Torvalds
2017-02-22 18:58                     ` Jens Axboe
2017-02-22 19:04                       ` Linus Torvalds
2017-02-22 21:29                         ` Jens Axboe
2017-02-22 18:42             ` Linus Torvalds
2017-02-22 18:44               ` Jens Axboe
2017-02-22 21:50                 ` Markus Trippelsdorf
2017-02-22 21:55                   ` Jens Axboe
2017-02-23  0:16                   ` Linus Torvalds

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=ef431f1c-e3c6-4940-bb2a-f5131ca96855@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.