linux-kernel - Re: [PATCH] block: allow specifying default iosched in config

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: <CACGdZYKvTLd0g2yBuFX+++XeSa6aapuAwOM7e63zhKgdKFEGEw@mail.gmail.com>
Date:   Tue, 4 Oct 2022 16:15:20 -0700
From:   Khazhy Kumykov <khazhy@...gle.com>
To:     Damien Le Moal <damien.lemoal@...nsource.wdc.com>
Cc:     Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: allow specifying default iosched in config

On Tue, Oct 4, 2022 at 3:40 PM Damien Le Moal
<damien.lemoal@...nsource.wdc.com> wrote:
>
> On 10/5/22 03:33, Khazhy Kumykov wrote:
> > On Mon, Oct 3, 2022 at 11:12 PM Damien Le Moal
> > <damien.lemoal@...nsource.wdc.com> wrote:
> >>
> >> This will allow a configuration to specify bfq or kyber for all single queue
> >> devices
> > That's the idea
> >> , which include SMR HDDs. Since these can only use mq-deadline (or none
> >> if the user like living dangerously), this default config-based solution is not
> >> OK in my opinion.
> > I don't think this is true - elevator_init_mq will call
> > elevator_get_by_features, not elevator_get_default for SMR hdds (and
> > other zoned devices), as it sets required_elevator_features.
>
> OK, but my point remains: why not use a udev rule ? Why add a config
> option to hardcode the default scheduler ? Most average users will have no
> idea which one to choose...
The kernel already picks and hardcodes a default scheduler, my
thinking is: why not let folks choose? This was allowed in the old
block layer since 2005.

My first thought was it'd be handy to have the kernel just start up
with the scheduler we wanted, rather than rely on userspace to listen
to an event to fix it.
But, some userspaces do not run a udev daemon (e.g. linuxboot, to my
recollection, others), so would need to stand one up, just for this.

Khazhy
>
> >>
> >> What is wrong with using a udev rule to set the default disk scheduler ? Most
> >> distros do that already anyway, so this config may not even be that useful in
> >> practice. What is the use case here ?
> >>
> >>
> >> --
> >> Damien Le Moal
> >> Western Digital Research
> >>
>
> --
> Damien Le Moal
> Western Digital Research
>

Download attachment "smime.p7s" of type "application/pkcs7-signature" (3999 bytes)