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