Re: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?

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

 



Hi,

Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes:

> Really Readding devel@ this time...
>
> On Wed, Dec 12, 2018 at 11:08 AM stan <stanl-fedorauser@xxxxxxxxxxx> wrote:
>>
>> On Tue, 11 Dec 2018 11:48:29 -0000
>> "Alan Jenkins" <alan.christopher.jenkins@xxxxxxxxx> wrote:
>>
>> > [3] BFQ:
>> > http://algo.ing.unimo.it/people/paolo/disk_sched/description.php
>> >
>> > [4]
>> > https://unix.stackexchange.com/questions/375600/how-to-enable-and-use-the-bfq-scheduler
>> >
>> > [5] "I'd prefer if the distros would lead the way on this, as theyare
>> > the ones that will most likely see the most bug reports" - Jens
>> > Axboe, https://www.spinics.net/lists/linux-block/msg31062.html
>>
>> I compiled a custom kernel from the fedora src.rpm for 4.19.8.  I turned
>> off all schedulers except NOOP and BFQ.  But there was no way in the
>> configuration process (make menuconfig) to set BFQ as default.  I tried
>> setting it in kernel-local, but the build process errored because it
>> said NOOP is the default and that disagreed with my choice.  I'm
>> running the kernel and it is using noop.  And there is no way to change
>> it in the /sys hierarchy.
>>
>> So, how do I get a fedora kernel to run BFQ?
>
> Short version:
> Yep, so far in 4.20 there is neither a CONFIG_DEFAULT_BFQ or
> CONFIG_DEFAULT_IOSCHED="bfq" near as I can tell. Maybe it's different
> for 4.21.

There isn't an option to select a default mq I/O scheduler, and I don't
think there will be in the future, either.  For mq devices, the kernel
policy is to use mq-deadline for single queue devices (so long as
mq-deadline is available), and to not specify an elevator otherwise.

Note that you can change the current I/O scheduler for any block device
by echo-ing into /sys/block/<dev>/queue/scheduler.  Cat-ing that file
will give you the list of available schedulers.

> I used two boot params: scsi_mod.use_blk_mq=1 elevator=bfq. I don't
> think that's a good way for a distribution to set the default though.

You shouldn't need the "scsi_mod.use_blk_mq=1" option.  As of 4.19,
scsi_mq is the default, and by 4.21 the legacy path will be gone.  The
right way for the distro to set the default I/O scheduler is to use udev
rules.

Choosing an I/O scheduler really needs to take two things into account:
1) the properties of the storage
2) the intended workload
okay, 3 things:
3) required features (such as proportional I/O control, which is only
   available via bfq)

It's not easy to divine any of those from a udev rule, unfortunately,
though heuristics can be applied.  What we've done in the past is to
pick an I/O scheduler that works reasonably well for all storage and
workloads we care about.  That involves (obviously) testing each I/O
scheduler for each combination of storage and workload you want to
support.  The goal is to avoid the worst case scenarios, not necessarily
to achive the best performance.

It's worth noting that tuned profiles can also be used to change the I/O
scheduler for data disks.  I think tuned leaves the OS disk alone.

> Icky version:
>
> I set the following in /etc/default/grub and then ran grub2-mkconfig
> (not on Rawhide!)
> GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=1 elevator=bfq zswap.enabled=1
> zswap.max_pool_percent=25 zswap.compressor=lz4"
>
> I also created  /etc/dracut.conf.d/bfq.conf containing:
> add_drivers+=" bfq "
> yes, with spaces, and rebuilt the initramfs
>
> But upon reboot, total implosion. Piles of USB errors and disconnects
> (the boot device is a Samsung FIT USB stick which fits flush in an
> Intel NUC). I didn't have time to troubleshoot what's causing this
> problem, other than to plug the USB stick into another computer to
> verify the stick is good and hasn't been corrupted. It's possibly
> related the mq-blk bug in 4.19.0 through 4.19.7 - so I've since
> upgraded to 4.19.8 which as those patches, but I haven't had a chance
> to retest.

That sounds awful.  It would be good if you could test the latest kernel
and report the problem upstream if it still exists there.

Thanks!
Jeff
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux