Announcement

Collapse
No announcement yet.

Should Ubuntu Use The BFQ I/O Scheduler?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Britoid View Post

    Does porn load quicker?
    Some people like the video to finish loading before they finish.

    Comment


    • #32
      Originally posted by FlawlessVolcano View Post

      Both NOOP and Deadline were deleted from kernel couple releases ago, so yes BFQ is certainly better than some non-existing code...
      Have you never seen poorly written code? There are plenty of examples of non-existing code being the better deal

      Comment


      • #33
        Originally posted by carewolf View Post

        blk-mq was not on by default for me, to even use BFQ, I had to first enable blk-mq on the kernel command-line, update grub and reboot. Debian probably changed the default to off for blk-mq.
        Then you are using a kernel that is at least ~9 months old, I'd suggest you use a current kernel before you pass judgement on an I/O scheduler that is under active development.

        Comment


        • #34
          Originally posted by Space Heater View Post

          Then you are using a kernel that is at least ~9 months old, I'd suggest you use a current kernel before you pass judgement on an I/O scheduler that is under active development.
          It is Linux, everything is always under active development and BFQ is several years old. And from what I gathered from the documentation. The issue is simply a better default in CFQ. If BFQ has implemented the same default, they have done so very recently and without updating the documentation.

          Comment


          • #35
            Is the BFQ scheduler worth it on NVMe drives?

            Comment


            • #36
              Originally posted by tildearrow View Post

              Can somebody ever care about HDD?
              Do people still use those these days?

              Comment


              • #37
                Originally posted by carewolf View Post
                It is Linux, everything is always under active development and BFQ is several years old. And from what I gathered from the documentation. The issue is simply a better default in CFQ. If BFQ has implemented the same default, they have done so very recently and without updating the documentation.
                BFQ wasn't merged until 4.12 as it had to be rewritten to be multiqueue-aware. Paolo is sending in improvements and fixes every release, which is not the case with other schedulers, it is by far the most active IO scheduler in terms of development. The fact is, you are using an old kernel which has an early version of blk-mq (before it was deemed ready to be the default) and an early version of bfq.

                By the way bfq does inherit ionice priorities from the task's CPU niceness if no IO priority class is set, this has been the default since it was first introduced.
                See: https://git.kernel.org/pub/scm/linux...osched.c#n4895

                Comment


                • #38
                  I have pretty bad experience with BFQ on 4.19.x kernels. Massive IO can block desktop for tens of seconds.

                  Comment


                  • #39
                    Originally posted by uid313 View Post
                    Do people still use those these days?
                    Of course, especially with large amounts of storage. Not sure large amounts of responsiveness would matter though.

                    Comment


                    • #40
                      Originally posted by uid313 View Post

                      Do people still use those these days?
                      Yes. I still do, and many people around here do too.

                      Why can't you understand you simply can't drop support for hardware that is still being actively released only because a new technology came out?
                      Yeah, I know SSD tech has been out in the market for like 9 years, but they still make HDDs.

                      Comment

                      Working...
                      X