On Thu, Feb 2, 2023 at 7:04 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > On 2/2/23 8:22 AM, Ulf Hansson wrote: > > On Tue, 31 Jan 2023 at 09:47, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >> > >> If we enable the MMC/SD block layer, use Kconfig to imply the BFQ > >> I/O scheduler. > >> > >> As all MMC/SD devices are single-queue, this is the scheduler that > >> users want so let's be helpful and make sure it gets > >> default-selected into a manual kernel configuration. It will still > >> need to be enabled at runtime (usually with udev scripts). > >> > >> Cc: linux-block@xxxxxxxxxxxxxxx > >> Cc: Paolo Valente <paolo.valente@xxxxxxxxxx> > >> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > > > > I have taken the various arguments (for and against), but I think > > $subject patch makes sense to me. In the end, this is about moving > > towards a more sensible default kernel configuration and the "imply" > > approach works fine for me. > > > > More importantly, $subject patch doesn't really hurt anything, as it's > > still perfectly fine to build MMC without I/O schedulers and BFQ, for > > those configurations that need this. > > > > That said, applied for next, thanks! > > It doesn't make sense, for all the reasons that Christoph applied. > But you guys seemed to already have your mind made up and ignoring > valid feedback, so... The history leading us here as I see it: In 2017 or if it was 2016 I think Paolo and Ulf started to look into BFQ for improving the user experience with MMC on embedded devices such as phones, tablets etc. I.e all systems using it. As BFQ was not accepted for the old block layer it was adopted for the MQ rewrite, as I understood a bit as "the new CFQ" for slow single-queued devices. Then, the MMC subsystem was consequently rewritten to use MQ to be able to take advantage of BFQ. It's why we pushed the conversion to MQ. To the point of creating social conflicts I might add. Not everyone loved converting MMC to MQ. Those changes are direct causes and effects, one to one. And now today all that work has made it possible for the MMC subsystem to perform as we wanted it to. Most MMC systems are interactive human operator-facing devices where interactivity matters. Any other MMC storage is secondary, uncommon and unimportant. It is called MultiMedia Card for a reason. So for MMC BFQ is a sensible default as an interactivity boosting scheduler. The kernel should provide sensible defaults. I do not see why it is not a sensible default for systems with MMC. Yours, Linus Walleij
