linux-kernel - Re: [PATCH] block: Default to build the BFQ I/O scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdY8DbvSMcf00zSwm5z1v3nWKMoJ+wYL90E9iR2W2hpvCw@mail.gmail.com>
Date:   Mon, 30 Jan 2023 11:44:51 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>, linux-block@...r.kernel.org,
        Paolo Valente <paolo.valente@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: Default to build the BFQ I/O scheduler

On Fri, Jan 27, 2023 at 9:10 PM Jens Axboe <axboe@...nel.dk> wrote:

> On 1/27/23 8:58 AM, Ulf Hansson wrote:
> > On Fri, 27 Jan 2023 at 16:48, Jens Axboe <axboe@...nel.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