On Tue, Oct 4, 2022 at 3:40 PM Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx> wrote: > > On 10/5/22 03:33, Khazhy Kumykov wrote: > > On Mon, Oct 3, 2022 at 11:12 PM Damien Le Moal > > <damien.lemoal@xxxxxxxxxxxxxxxxxx> 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 >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
