From patchwork Tue Feb 21 23:15:53 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 9585877 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2E160601A1 for ; Tue, 21 Feb 2017 23:15:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1249628606 for ; Tue, 21 Feb 2017 23:15:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0433028611; Tue, 21 Feb 2017 23:15:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63CD328606 for ; Tue, 21 Feb 2017 23:15:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753251AbdBUXP4 (ORCPT ); Tue, 21 Feb 2017 18:15:56 -0500 Received: from mail-io0-f176.google.com ([209.85.223.176]:33164 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752949AbdBUXPz (ORCPT ); Tue, 21 Feb 2017 18:15:55 -0500 Received: by mail-io0-f176.google.com with SMTP id g18so33123872ioe.0 for ; Tue, 21 Feb 2017 15:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=D+Q0wMhlfnschxKrnjMoymnS5XF4SAnC8viP9ddzAWw=; b=aLvYmirJDBa0GDARCAQtIv3PJ8Pg9v+mD64OMkzToRjCd0Zn6rVEtu7ElsWUtaQ3Oi vdkhGjQFcFaXWqgBoVainlgcoWPvTUsOcZF6XoHaE9DQ8ytJYG3gZ8VnmTypOUfTk1Wa ONL8uwE3jA8AbhfoOi692eh2Kt8U0YjByvORzeKV3BTrzGubEwCdv8kip/M8jOSv/sbe vrEynLg45o2n6aRReDFFFhXyeVQ1A8DylqldcdVY2UCJaLG/dHXfeo+LtUhw/pmlziKW 01chpmjlZMwE7HxfTBZuijiuAsohHh/oRj4j8nXNwJIuXISUsG1YKjI++EI0yXxzE3bw v+JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=D+Q0wMhlfnschxKrnjMoymnS5XF4SAnC8viP9ddzAWw=; b=WtefuIC9/bLf4UC9wrQNWqMfmBxE483xNtVXxxW69ylVMYkBFnc0FrWwquHEOROs4N zhwJl/NYVvpBn3IAX/0sRU7km6JXV/uxLRJF4iDltJQVmMTbpVBF/ittP26Rz3iQsIRe Y2T2AJnk1p6C0m/KddvVAF64ULt76+9qoCGthiHo8ZbFNHVnPWnJRs/P3xdvWaBjIkdG /VU6Ys4LkqHuKvvjqg9ycfLl92e/gnVy1BHWaMQgLcZ8vQEzo2ImXPIkYKxb1TmxrsgV tJOBdxoo4CYS4lsh+GD1Xb0jbfo22szp+mm5HvmUvkLDogFnDWsKGffeAAXjFj3brAGj BBwA== X-Gm-Message-State: AMke39kMB7q4cwIBQpJywO9isQDWS9sDnxMlO26nf8n5v/K8Urc/rVZU2QMCfgRIYJd+nw== X-Received: by 10.107.1.9 with SMTP id 9mr17966027iob.179.1487718954726; Tue, 21 Feb 2017 15:15:54 -0800 (PST) Received: from [192.168.1.154] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id q65sm10821060ioe.16.2017.02.21.15.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 15:15:54 -0800 (PST) Subject: Re: [GIT PULL] Block pull request for- 4.11-rc1 To: Linus Torvalds References: Cc: "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Jens Axboe Message-ID: Date: Tue, 21 Feb 2017 16:15:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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.