Announcement

Collapse
No announcement yet.

Chromebooks Switching Over To The BFQ I/O Scheduler

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

  • Chromebooks Switching Over To The BFQ I/O Scheduler

    Phoronix: Chromebooks Switching Over To The BFQ I/O Scheduler

    On Chromebooks when moving to the latest Chrome OS that switches over to a Linux 4.19 based kernel, BFQ has become the default I/O scheduler...

    http://www.phoronix.com/scan.php?pag...BFQ-Default-IO

  • #2
    BFQ aims for low latency on interactive and soft real-time tasks while still being capable of achieving high throughput, among other benefits.
    Looking forward to it. Low latency has been one of those sore spots of Linux on the desktop for SO MANY YEARS... Traditionally, Linux has always had this trade off: do we want to maximize throughput for the data center, or do we want to minimize latency for the desktop? Historically, the data center apparently was more important or perhaps easier to solve for Linux devs...

    I want to use Linux for music synthesizers and games and stuff like that, but the non-deterministic high latency aspect just kills me. When a musician hits a key on their piano keyboard, they really need to have the sound come out of their speakers immediately, without significant delays and definitely without unpredictable intermittent delays. Jankiness may be tolerable for web servers, but completely intolerable for real-time music synthesis.

    Comment


    • #3
      Originally posted by ed31337 View Post
      I want to use Linux for music synthesizers and games and stuff like that, but the non-deterministic high latency aspect just kills me. When a musician hits a key on their piano keyboard, they really need to have the sound come out of their speakers immediately, without significant delays and definitely without unpredictable intermittent delays. Jankiness may be tolerable for web servers, but completely intolerable for real-time music synthesis.
      I agree. Linux 4.9 with RT patches was the most stable version for me during 2017, often hitting 0 xruns on JACK with 128-sample buffers.
      Now I have to work with 160-sample buffers, because 128 causes some xruns...

      Also, please note that the piano keyboard thingy is only true for keyboards (and controllers) with lightweight keys (the majority of them). In a real piano, it takes a short while for the hammer to hit the string on a key press.
      Last edited by tildearrow; 08-20-2019, 04:03 PM.

      Comment


      • #4
        For real-time music processing you should be using jack to circumvent the scheduling: https://wiki.archlinux.org/index.php...Connection_Kit

        For general purpose responsiveness Arch's wiki's recommended udev rules are often cited and are better than the defaults: https://wiki.archlinux.org/index.php..._I/O_scheduler

        However, as the story suggests, in edge cases like low-power laptops, there are power-performance considerations that, following profiling, might make you want to use a different I/O scheduler since the tradeoff isn't worth it.

        Personally unless it's mission critical, I don't tinker with the defaults anymore since contemporary hardware feels fast enough for me. Then again, I don't process music or game either so that's just me

        Comment


        • #5
          Originally posted by tildearrow View Post
          Also, please note that the piano keyboard thingy is only true for keyboards (and controllers) with lightweight keys (the majority of them). In a real piano, it takes a short while for the hammer to hit the string on a key press.
          That's only true for an upright pianos. Grand pianos don't use a spring for the hammer.

          Comment


          • #6
            I’m sure BFQ is great but in the video he didn’t clear the caches between both tests, so it doesn’t prove anything…

            Comment


            • #7
              Originally posted by stqn View Post
              I’m sure BFQ is great but in the video he didn’t clear the caches between both tests, so it doesn’t prove anything…
              View the videos comments, it's explained that clearing caches had been used in an earlier experiment and made no difference(with this test), they just forgot to clarify that on the video.

              AFAIK, this is the behaviour of the deadline scheduler isn't? To process a request and then handle the next I/O request? So regardless of being in the cache, deadline might still wait until that dd I/O has completed before moving onto the next request?

              Comment


              • #8
                I love brain fuck, hilarious that it needed to be renamed before anyone would consider using it. :- )

                Comment


                • #9
                  Originally posted by microcode View Post
                  I love brain fuck, hilarious that it needed to be renamed before anyone would consider using it. :- )
                  This isn't BFS, it is Budget Fair.

                  Comment


                  • #10
                    Well it seems single queue schedulers like CFQ were removed/deprecated in Linux 5.0, so maybe that's why Google changed it.

                    Comment

                    Working...
                    X