Announcement

Collapse
No announcement yet.

MuQSS Scheduler Updated, Linux 4.19-ck1 Drops BFQ I/O Scheduler

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

  • MuQSS Scheduler Updated, Linux 4.19-ck1 Drops BFQ I/O Scheduler

    Phoronix: MuQSS Scheduler Updated, Linux 4.19-ck1 Drops BFQ I/O Scheduler

    Con Kolivas is out with an updated version of his MuQSS scheduler (based on his former Brain BFS Scheduler work) as well as his "-ck" patch-set against the mainline kernel...

    http://www.phoronix.com/scan.php?pag...4.19-ck1-MuQSS

  • #2
    In Ubuntu 18.10 BFQ isn't even mentioned:
    cat /sys/block/sda/queue/scheduler
    outputs:
    noop deadline [cfq]

    Comment


    • #3
      Originally posted by cl333r View Post
      In Ubuntu 18.10 BFQ isn't even mentioned:
      cat /sys/block/sda/queue/scheduler
      outputs:
      noop deadline [cfq]
      Even Kyber isn't mentioned :/ Strange. Here on Solus, they are mentioned. CFQ isn't, though (which I don't care about as I prefer Kyber or BFQ anyway).

      cat /sys/block/sda/queue/scheduler
      mq-deadline [kyber] bfq none

      Comment


      • #4
        Originally posted by Phoronix
        ...based on his former Brain BFS Scheduler work...
        It's called either BFS or Brain Fuck Scheduler, I'm not quite sure what you're referring to

        Comment


        • #5
          $ cat /sys/block/sda/queue/scheduler
          [none] mq-deadline kyber bfq

          I'm a none kind of guy myself ​​

          For a while I was trying out CK's MuQSS and Alfred Chen's PDS (based off CK's BFS) but ran into some instability (crashes found in /var/crash), and I wasn't contributing to bug reports so I just stopped using them.

          Would be great to see some benchmarks comparing those two and the vanilla kernel, if you have free time.

          if (Michael && freeTime) {
          // we never get here
          }

          Comment


          • #6
            Originally posted by cl333r View Post
            In Ubuntu 18.10 BFQ isn't even mentioned:
            cat /sys/block/sda/queue/scheduler
            outputs:
            noop deadline [cfq]
            Adding this to the kernel parameters (e.g. /etc/default/grub) will do:
            Code:
            scsi_mod.use_blk_mq=1
            (UPDATE: this may be dangerous)
            Last edited by tildearrow; 12-04-2018, 08:26 PM. Reason: update for 4.19 issue

            Comment


            • #7
              Linux desktop users have been plagued with audio stutters and mouse cursor skipping issue for years, I easily run into this issue on just about any computer, all it takes is put 100% IO load on any storage device e.g. scard/usb flashdrive/external hdd by doing simple thing like copying a file and you just watch iowait number ramp up and experience totally unresponsive system. I can't recall what used be a decent kernel, it has been so long, but I remember 2.6.20~2.6.24 working well back in gcc 3.2 days. I'm really sad. Nobody really cares about this because kernel developers are paid by big companies and their target is CFS a systems with >= 1024 threads, that's were CFS performs well. Not only that, the kernel developers don't test for performance regressions outside their workload. Typical desktop users with quadcore cpus are left in dust.

              Comment


              • #8
                Originally posted by tildearrow View Post

                Adding this to the kernel parameters (e.g. /etc/default/grub) will do:
                Code:
                scsi_mod.use_blk_mq=1
                Didn't work:
                Code:
                GRUB_DEFAULT=0
                GRUB_TIMEOUT_STYLE=hidden
                GRUB_TIMEOUT=10
                GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
                GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
                GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=1"

                Comment


                • #9
                  Originally posted by hax0r View Post
                  Linux desktop users have been plagued with audio stutters and mouse cursor skipping issue for years, I easily run into this issue on just about any computer, all it takes is put 100% IO load on any storage device e.g. scard/usb flashdrive/external hdd by doing simple thing like copying a file and you just watch iowait number ramp up and experience totally unresponsive system. I can't recall what used be a decent kernel, it has been so long, but I remember 2.6.20~2.6.24 working well back in gcc 3.2 days. I'm really sad. Nobody really cares about this because kernel developers are paid by big companies and their target is CFS a systems with >= 1024 threads, that's were CFS performs well. Not only that, the kernel developers don't test for performance regressions outside their workload. Typical desktop users with quadcore cpus are left in dust.
                  There are some kernel values you can alter to help with those issues:

                  https://wiki.archlinux.org/index.php/Swap#Swappiness

                  https://rudd-o.com/linux-and-free-so...ow-to-fix-that

                  Comment


                  • #10
                    Important to note a comment from damentz (Zen kernel developer) on CK's blog post:

                    BFQ has only recently gotten, very good. If you've been running mainline, the final patches that make BFQ worthwhile probably just got merged in 4.19. Otherwise, if you've been running the Algodev/bfq-mq branch already, then BFQ has been behaving properly for a few months now.

                    Secondly, the legacy block subsystem caused a lot of problems that BFQ has no control over. The newer 'blk-mq' subsystem seems to reduce problems the legacy block incurred, letting BFQ do its thing.

                    Comment

                    Working...
                    X