Re: [PATCH] mmc: core: Imply IOSCHED_BFQ

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux