Message ID | 20230127154339.157460-1-ulf.hansson@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp901371wrn; Fri, 27 Jan 2023 07:47:07 -0800 (PST) X-Google-Smtp-Source: AK7set8IBZts1gKP2HUpeEgJUkRKc/JFiEKxJdP++66tcSD/+NmogBJkY1hedj7NRca+/IOlv++T X-Received: by 2002:a17:902:ce89:b0:196:1ab9:afc8 with SMTP id f9-20020a170902ce8900b001961ab9afc8mr15930875plg.4.1674834427048; Fri, 27 Jan 2023 07:47:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674834427; cv=none; d=google.com; s=arc-20160816; b=YS7T+VOPPYTxuSp8wyPzZ8Z+wK4qrhV9xleoDYG8Hi25Qm1cfPFmeu2pnqV9gtPdUc VtW2+AwJegrnwxC8sVKeSZ7MfwVtO0uGXFOtrjUnOpXJ4lTJlo2bXog1Lkg7ly+P1lEu v1yQ6EHBkYpDnYSU9zn6QkwBnYVvApDp+3g16rfOCIH6lLvE3Xz+PrZOQMc4TLsVQasx RYL0kicLDF4N7IagIY6OeBRtTKNik3XiftXku4NnRsKj9PS/bKVvEJu6PX+FNRIuvA2m rHAZ5Zh95tknBclsdhmkdKGNIpApVsFTb1gNFbH+mlbABP4H8OkhZOvBT0eNYFA4ux58 Tc3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=C0XbD0jJdU2x+omBw0qnilPtQJrXIbuZZfbb07Z77I0=; b=bEAdNouSyeHQ/1c6ndwvjrSJux09PSU1kuodGYUHB5ScKrdVH6naTe5DptaISpBxIx LUwl00Kj87DqD5g6t8Iz3m+zcgheRSIZNagD5xWfIO/NE/jJ0m/fbXsaJkr4gxt6DBGV S7gw5TBw7L+Sb7ThuBsWfjYNz9ty8p8AYbCjfKBC2W5g60FFlaRO1C3KcgnTS9uVx/q4 U0z4+s0h5FXrcBAxIg0o6tjn1YY7Fif8uuo649wN1+E94/UkpcXM31/vZnPN57ivFSpK z8sjqUoLqYYrWNdqq+x4klEQFnGEqe3fbxivJvp8gSWF+ZbOI/Lnjpq/g1e3moXu9tcu Lt6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=rhn6HiKj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w8-20020a637b08000000b004daa0a4a4eesi4738841pgc.174.2023.01.27.07.46.55; Fri, 27 Jan 2023 07:47:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=rhn6HiKj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232385AbjA0PoA (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Fri, 27 Jan 2023 10:44:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232456AbjA0Pn4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Jan 2023 10:43:56 -0500 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69DEE83951 for <linux-kernel@vger.kernel.org>; Fri, 27 Jan 2023 07:43:49 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id vw16so14700706ejc.12 for <linux-kernel@vger.kernel.org>; Fri, 27 Jan 2023 07:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=C0XbD0jJdU2x+omBw0qnilPtQJrXIbuZZfbb07Z77I0=; b=rhn6HiKjfZwLaFGQK38vDp9w1cvhdoUbh8rp3/CF5hFP/JeLDKrD1AwCYvOyo+ftVM hva82F6VMCtIlwPj7I2iC9zPtpKPz5QijVb1HvKPXjwS1GLz0LoGMTr1spq7AeDUg9a1 WxU/bfsL9xGibKLvrEXk9auUZmnuqUR1Ui3yd4dUnUCYMLfPr3CCn9o09ipOLmqpfy92 i383zdPhTal2L2M2CWT9NdysSC5DoWiWD0OodJk3KEJSfuOrMYgUIp8c4YhcVq3VN20R ziqnBJsRLSt3BKSMMP2DlnTjJVakTNBGvdRuMe5JPN15DqlmH1PTnR+9KpUA4WwPGg+I Nkug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C0XbD0jJdU2x+omBw0qnilPtQJrXIbuZZfbb07Z77I0=; b=kiuzCoeps2SbGVA+4mHSRtc0Y/MksETnhr8kX8u/0+xZQq9u946Vgm33GgOji5DsLq Mlu8sa0wbXnjnWWHoeMMwbY0qh125lmN2anOYWxdBpI+qYDt+2lCEEM8WbG7DKIV9WDQ EoRMYL9de2kavzdxd9Tla+PGwgvE0bNgTJqfOZtmPTiWPBk+uycurTuFPVbbTq5Tj0Ve qF+lmPvk5B3YxR2lLwp1Q8VqNLTzLJIo93CGRiSo677oCLQG3kxldaaHxDrF6wJyyB1d cNg45mBLUNK4cN7FA+NBhaOnPZ/mwwklHapYShYMyqMfHVlZVXSc8Y8F2mSgLNfhLPbb mpOg== X-Gm-Message-State: AFqh2krASiJjYxEclAsqv43HYMKiSFNHyiGOrEW+tBQHV0Be/BlrlZyD GLUx8QTY8XnglV2ejuzLWYXBEw== X-Received: by 2002:a17:906:3291:b0:86f:356e:ba43 with SMTP id 17-20020a170906329100b0086f356eba43mr40042800ejw.18.1674834227901; Fri, 27 Jan 2023 07:43:47 -0800 (PST) Received: from uffe-XPS13.. (h-94-254-63-18.NA.cust.bahnhof.se. [94.254.63.18]) by smtp.gmail.com with ESMTPSA id va17-20020a17090711d100b00876479361edsm2467611ejb.149.2023.01.27.07.43.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jan 2023 07:43:47 -0800 (PST) From: Ulf Hansson <ulf.hansson@linaro.org> To: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org Cc: Paolo Valente <paolo.valente@linaro.org>, Linus Walleij <linus.walleij@linaro.org>, linux-kernel@vger.kernel.org, Ulf Hansson <ulf.hansson@linaro.org> Subject: [PATCH] block: Default to build the BFQ I/O scheduler Date: Fri, 27 Jan 2023 16:43:39 +0100 Message-Id: <20230127154339.157460-1-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756191184382570273?= X-GMAIL-MSGID: =?utf-8?q?1756191184382570273?= |
Series |
block: Default to build the BFQ I/O scheduler
|
|
Commit Message
Ulf Hansson
Jan. 27, 2023, 3:43 p.m. UTC
Today BFQ is widely used and it's also the default choice for some of the
single-queue-based storage devices. Therefore, let's make it more
convenient to build it as default, along with the other I/O schedulers.
Let's also build the cgroup support for BFQ as default, as it's likely that
it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
block/Kconfig.iosched | 2 ++
1 file changed, 2 insertions(+)
Comments
On 1/27/23 8:43 AM, Ulf Hansson wrote: > Today BFQ is widely used and it's also the default choice for some of the > single-queue-based storage devices. Therefore, let's make it more > convenient to build it as default, along with the other I/O schedulers. > > Let's also build the cgroup support for BFQ as default, as it's likely that > it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course. This won't make much of a difference, when the symbols are already in the .config. So let's please not. It may be a 'y' for you by default, but for lots of others it is not. Don't impose it on folks.
On Fri, 27 Jan 2023 at 16:48, Jens Axboe <axboe@kernel.dk> wrote: > > On 1/27/23 8:43 AM, Ulf Hansson wrote: > > Today BFQ is widely used and it's also the default choice for some of the > > single-queue-based storage devices. Therefore, let's make it more > > convenient to build it as default, along with the other I/O schedulers. > > > > Let's also build the cgroup support for BFQ as default, as it's likely that > > it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course. > > This won't make much of a difference, when the symbols are already in > the .config. So let's please not. It may be a 'y' for you by default, > but for lots of others it is not. Don't impose it on folks. This isn't about folkz, but HW. :-) I was thinking that it makes sense for the similar reason to why kyber and deadline are being built as default. Or are there any particular other reasons to why we build those in as default, but not BFQ? Kind regards Uffe
On 1/27/23 8:58 AM, Ulf Hansson wrote: > On Fri, 27 Jan 2023 at 16:48, Jens Axboe <axboe@kernel.dk> wrote: >> >> On 1/27/23 8:43 AM, Ulf Hansson wrote: >>> Today BFQ is widely used and it's also the default choice for some of the >>> single-queue-based storage devices. Therefore, let's make it more >>> convenient to build it as default, along with the other I/O schedulers. >>> >>> Let's also build the cgroup support for BFQ as default, as it's likely that >>> it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course. >> >> This won't make much of a difference, when the symbols are already in >> the .config. So let's please not. It may be a 'y' for you by default, >> but for lots of others it is not. Don't impose it on folks. > > This isn't about folkz, but HW. :-) Is it everybody? No, it's a subset. Everybody adding a new driver wants to default to y/m, and it's almost always wrong. > I was thinking that it makes sense for the similar reason to why kyber > and deadline are being built as default. Or are there any particular > other reasons to why we build those in as default, but not BFQ? deadline arguably makes sense as it's simple, and we should have one default scheduler. kyber probably does not need to be default y. But at least that one doesn't pull in other dependencies.
On Fri, Jan 27, 2023 at 4:48 PM Jens Axboe <axboe@kernel.dk> wrote: > On 1/27/23 8:43 AM, Ulf Hansson wrote: > > Today BFQ is widely used and it's also the default choice for some of the > > single-queue-based storage devices. Therefore, let's make it more > > convenient to build it as default, along with the other I/O schedulers. > > > > Let's also build the cgroup support for BFQ as default, as it's likely that > > it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course. > > This won't make much of a difference, when the symbols are already in > the .config. So let's please not. It may be a 'y' for you by default, > but for lots of others it is not. Don't impose it on folks. This part: config BFQ_GROUP_IOSCHED bool "BFQ hierarchical scheduling support" depends on IOSCHED_BFQ && BLK_CGROUP + default y select BLK_CGROUP_RWSTAT help should certainly be fine. If you select BFQ then it is helpful to get the group scheduler as well if you have BLK_CGROUP, so Ulf could you please send this part separately with that motivation? For the selection of BFQ_IOSCHED: As major distributions have it in their .configs it is kind of established standard for them. The general policy is that the kernel should provide "sensible defaults", so it is easy to make correct choices even if starting from scratch, relying on a few different out-of-kernel .configs from different distros isn't helpful for someone starting from scratch. What about default enabling it when enabling the relevant subsystems? The udev script looks like so: ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", \ KERNEL=="mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|sd*[!0-9]|sr*", \ ATTR{queue/scheduler}="bfq" i.e. drivers/[mmc|memstick|scsi|ata|cdrom] This can be achieved by adding weak reverse dependencies to these subsystems, meaning it will not be default-selected unless you make use of one of them, and even then it can be manually removed (in difference from using "select"). Example: diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index 6f25c34e4fec..52fe9d7c21cc 100644 --- a/drivers/mmc/core/Kconfig +++ b/drivers/mmc/core/Kconfig @@ -37,6 +37,7 @@ config PWRSEQ_SIMPLE config MMC_BLOCK tristate "MMC block device driver" depends on BLOCK + imply IOSCHED_BFQ default y help Say Y here to enable the MMC block device driver support. Since all MMC devices will use BFQ on all major distributions this makes sense to me. Also it is a policy that can be chosen by each subsystem maintainer individually. There is however the bigger problem of how to make a system come up on eg MMC with BFQ on from the start, which I battled before but it can be treated as an orthogonal problem. Yours, Linus Walleij
On Fri, Jan 27, 2023 at 9:10 PM Jens Axboe <axboe@kernel.dk> wrote: > On 1/27/23 8:58 AM, Ulf Hansson wrote: > > On Fri, 27 Jan 2023 at 16:48, Jens Axboe <axboe@kernel.dk> wrote: > >> On 1/27/23 8:43 AM, Ulf Hansson wrote: > >>> Today BFQ is widely used and it's also the default choice for some of the > >>> single-queue-based storage devices. Therefore, let's make it more > >>> convenient to build it as default, along with the other I/O schedulers. > >>> > >>> Let's also build the cgroup support for BFQ as default, as it's likely that > >>> it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course. > >> > >> This won't make much of a difference, when the symbols are already in > >> the .config. So let's please not. It may be a 'y' for you by default, > >> but for lots of others it is not. Don't impose it on folks. > > > > This isn't about folkz, but HW. :-) > > Is it everybody? No, it's a subset. Everybody adding a new driver wants > to default to y/m, and it's almost always wrong. This isn't about individual drivers, as I showed from the udev rules used by Fedora/Redhat it is clearly entire subsystems and hundreds of drivers that desire this. Ulf can certainly decide what is best for the MMC and memstick drivers. Thus I think it is probably best to make each subsystem that desire BFQ imply it. Yours, Linus Walleij
On Fri, 27 Jan 2023 at 21:10, Jens Axboe <axboe@kernel.dk> wrote: > > On 1/27/23 8:58 AM, Ulf Hansson wrote: > > On Fri, 27 Jan 2023 at 16:48, Jens Axboe <axboe@kernel.dk> wrote: > >> > >> On 1/27/23 8:43 AM, Ulf Hansson wrote: > >>> Today BFQ is widely used and it's also the default choice for some of the > >>> single-queue-based storage devices. Therefore, let's make it more > >>> convenient to build it as default, along with the other I/O schedulers. > >>> > >>> Let's also build the cgroup support for BFQ as default, as it's likely that > >>> it's wanted too, assuming CONFIG_BLK_CGROUP is also set, of course. > >> > >> This won't make much of a difference, when the symbols are already in > >> the .config. So let's please not. It may be a 'y' for you by default, > >> but for lots of others it is not. Don't impose it on folks. > > > > This isn't about folkz, but HW. :-) > > Is it everybody? No, it's a subset. Everybody adding a new driver wants > to default to y/m, and it's almost always wrong. BFQ and I/O schedulers aren't just simple "drivers'', but common pieces of the storage stack. As pointed out by Linus in his other reply, instead this strives towards getting a sensible default configuration of the kernel. > > > I was thinking that it makes sense for the similar reason to why kyber > > and deadline are being built as default. Or are there any particular > > other reasons to why we build those in as default, but not BFQ? > > deadline arguably makes sense as it's simple, and we should have one > default scheduler. kyber probably does not need to be default y. But > at least that one doesn't pull in other dependencies. Alright, so it sounds like it's rather a matter of the code's complexity, whether it deserves to be default y or not. No? I would rather let all the three I/O schedulers be default y, as it looks like that would be the best default configuration of the kernel. But it looks like we don't agree on that. > > -- > Jens Axboe > > Kind regards Uffe
diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched index 615516146086..221739143d44 100644 --- a/block/Kconfig.iosched +++ b/block/Kconfig.iosched @@ -18,6 +18,7 @@ config MQ_IOSCHED_KYBER config IOSCHED_BFQ tristate "BFQ I/O scheduler" + default y select BLK_ICQ help BFQ I/O scheduler for BLK-MQ. BFQ distributes the bandwidth of @@ -30,6 +31,7 @@ config IOSCHED_BFQ config BFQ_GROUP_IOSCHED bool "BFQ hierarchical scheduling support" depends on IOSCHED_BFQ && BLK_CGROUP + default y select BLK_CGROUP_RWSTAT help