MIME-Version: 1.0
References: <20230127154339.157460-1-ulf.hansson@linaro.org>
 <5743fb1b-eb4b-d169-a467-ee618bcd75f5@kernel.dk> <CAPDyKFqFrB4h21F0901nBp-mpiP70nObOrCpRA0ZRfOD_kD5ug@mail.gmail.com>
 <3ba1adc6-4fb4-036c-8eca-91f549471c49@kernel.dk>
In-Reply-To: <3ba1adc6-4fb4-036c-8eca-91f549471c49@kernel.dk>
From:   Ulf Hansson <ulf.hansson@linaro.org>
Date:   Mon, 30 Jan 2023 12:56:36 +0100
Message-ID: <CAPDyKFpZSTJozGX5wy4=ePwFO6vZPgu4p5tpML_Cz-ZYSHyb2Q@mail.gmail.com>
Subject: Re: [PATCH] block: Default to build the BFQ I/O scheduler
To:     Jens Axboe <axboe@kernel.dk>
Cc:     linux-block@vger.kernel.org,
        Paolo Valente <paolo.valente@linaro.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 27 Jan 2023 at 21:10, Jens Axboe <axboe@kernel.dk> wrote:
>
> On 1/27/23 8:58=E2=80=AFAM, Ulf Hansson wrote:
> > On Fri, 27 Jan 2023 at 16:48, Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> On 1/27/23 8:43=E2=80=AFAM, 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 scheduler=
s.
> >>>
> >>> Let's also build the cgroup support for BFQ as default, as it's likel=
y 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