Announcement

Collapse
No announcement yet.

Some Fresh I/O Scheduler Benchmarks: Linux 4.13 With BFQ, CFQ, Kyber, Deadline

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

  • Some Fresh I/O Scheduler Benchmarks: Linux 4.13 With BFQ, CFQ, Kyber, Deadline

    Phoronix: Some Fresh I/O Scheduler Benchmarks: Linux 4.13 With BFQ, CFQ, Kyber, Deadline

    For those curious about the state of I/O schedulers with the in-development Linux 4.13 kernel, here are some fresh disk benchmarks using the 4.13 Git kernel on an Intel laptop/ultrabook and testing the various in-kernel options...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's a bit hard to read when there are different sets of schedulers in many of the tests...

    Comment


    • #3
      bfq should be better in linux 4.14

      Comment


      • #4
        Yes. Making colored bars would've made it easier to read. Still, nice benchmark. I guess BFQ low latency could one day be the scheduler of choice.

        Comment


        • #5
          Originally posted by wdb974 View Post
          I guess BFQ low latency could one day be the scheduler of choice.
          I got the same impression, but this was only a best case test for an IO scheduler – a fairly good SSD in a fairly good ultrabook.

          One thing is rotational disks of course, but I don't think that's where you find the worst case performance. No, I would like to see the same test on a Raspberry Pi with the shittiest class10 microSD card. Yes, class10 because that's what people think is best, yet is usually the worst at small reads/writes (because the rating criteria differ between the classes, with class6 being the golden class – the highest rating where small writes are considered. Performance of class10 and above is a lottery because nobody cares about random access).
          Last edited by andreano; 20 August 2017, 03:07 PM.

          Comment


          • #6
            Originally posted by wdb974 View Post
            I guess BFQ low latency could one day be the scheduler of choice.
            You're right: Not just making it the new default, they are discussing to actually replace CFQ!

            The author did thankfully test with a microSD card (class 6), and appears to be working for Linaro (above link), which soothes my initial skepticism.
            Last edited by andreano; 20 August 2017, 05:29 PM.

            Comment


            • #7
              The first benchmark is actually a spectacular bug report against CFQ. It should be mentioned on the kernel bugzilla.

              Comment


              • #8
                Im currently using Kernel 4.10 with the Con Kolivas patch set applied (includes BFQ v8) with BFQ enabled by default.

                Is the BFQ I/O scheduler in kernels 4.12 and 4.13 the same as the patch from Con Kolivas?
                I seem to remember reading somewhere they are not really the same thing.
                And how is BFQ low-latency different to normal BFQ?

                Comment


                • #9
                  Originally posted by flubba86 View Post
                  Im currently using Kernel 4.10 with the Con Kolivas patch set applied (includes BFQ v8) with BFQ enabled by default.

                  Is the BFQ I/O scheduler in kernels 4.12 and 4.13 the same as the patch from Con Kolivas?
                  I seem to remember reading somewhere they are not really the same thing.
                  And how is BFQ low-latency different to normal BFQ?
                  I believe the one in -ck is not a blk_mq scheduler.
                  As for low-latency, I think that removes most of the stuff that keeps the system responsive (responsiveness vs throughput).

                  Comment


                  • #10
                    Originally posted by geearf View Post
                    As for low-latency, I think that removes most of the stuff that keeps the system responsive (responsiveness vs throughput).
                    I think you have it backwards. Low-latency is responsive, high throughput has high-latency and is less responsive.

                    Comment

                    Working...
                    X