Announcement

Collapse
No announcement yet.

Linux 4.19 I/O Scheduler SSD Benchmarks With Kyber, BFQ, Deadline, CFQ

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

  • #11
    Originally posted by hax0r View Post
    Michael any chance you will have Liquorix kernel (https://liquorix.net/) tested alongside in upcoming benchmark articles? It is really easy to install on top of Ubuntu/Debian and is a drop-in replacement for stock ubuntu kernel.
    I usually test it 2~3 times a year... I suppose soon I will get around to trying it again.
    Michael Larabel
    https://www.michaellarabel.com/

    Comment


    • #12
      Originally posted by geearf View Post
      Unless I'm mistaken this test is it does not tell us much about latency, which for many of us is more important than throughput.
      I think the most important test is this: under heavy load, is the system still responsive enough? And lately that has not been the case on my system using BFQ which was supposed to be the whole point :/
      Unfortunately BFQ's latency tests in their latest form were breaking for me with this latest testing.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #13
        Originally posted by Michael View Post

        Unfortunately BFQ's latency tests in their latest form were breaking for me with this latest testing.
        That's no good :/
        Maybe that's why BFK isn't so good for this release.

        Comment


        • #14
          Originally posted by Michael View Post

          Unfortunately BFQ's latency tests in their latest form were breaking for me with this latest testing.
          I think it would be rather important to see latency results too. In fact, these new results show that BFQ is, finally, basically on par with the other blk-mq I/O schedulers, even on these throughput-only results. There are still issues with heavy writes, but we seem to have already found the cause, and are working on it.

          The good performance of deadline is actually telling much more than it may seem at a first glance: deadline is *identical* to mq-deadline, apart from living in legacy block instead of blk-mq. Therefore, deadline's better performance implies just that legacy block is still slightly better than blk-mq on your box. Don't tell it to Jens & co., as they are wiping out legacy block from 4.21

          Turning back to the only critical issue I see in these new interesting results, namely the absence of latency results, if those tests are still broken, I'm willing to fix them, as usual. Unfortunately, I cannot reproduce any malfunction on any of my machines. I'll write you privately to try to help with this issue, Michael.

          Comment


          • #15
            Originally posted by tildearrow View Post

            I call them "unstable" because of the EXT4 corruption issues, and because some people were reporting AMD troubles with 4.19 (yes, I know they are officially called "stable" but it doesn't feel like so).
            Well, I've been using 4.19.0 for 18 days 24/7 and 4.19.2 for 14 days now without any corruption. The system has 3 x ext4 partitions and 5 x btrfs. Seems to work just fine..

            Comment


            • #16
              Originally posted by geearf View Post
              Unless I'm mistaken this test is it does not tell us much about latency, which for many of us is more important than throughput.
              I think the most important test is this: under heavy load, is the system still responsive enough? And lately that has not been the case on my system using BFQ which was supposed to be the whole point :/
              This. Asking the right questions. Does anyone have idea about a test for this to add to the benchmarking?

              Comment


              • #17
                I'm still trying to figure out why my Linux servers hang when writing large amounts of data. I have been battling this for like 10+ years. Does not matter what scheduler I use. I've tried native board chipsets, external cards, different motherboards, everything, doesn't matter. If I write a large amount of data the whole system freezes up periodically. This is independent of the drive(s). A heavy write task to any drive periodically freezes the whole system.

                This is especially problematic in virtual machines. There MUST be something I'm doing wrong because cloud hosts don't seem to exhibit this behavior (or maybe I don't notice).

                So frustrating and this is not the right place to ask for help but I just throw this out everywhere hoping that someone, somewhere, knows what the problem is.

                Comment


                • #18
                  So there is something important for readers to try to understand here and that is that IO performance is -VERY- much a perceptive experience. Winning benchmarks can give great insight into performance potentials and such, but they don't tell you how a user experience "feels"....

                  My advice is to benchmark -your own- typical workload and judge the user experience for yourself.

                  Anyway this was a great benchmark run.

                  Comment


                  • #19
                    Originally posted by tildearrow View Post

                    I call them "unstable" because of the EXT4 corruption issues, and because some people were reporting AMD troubles with 4.19 (yes, I know they are officially called "stable" but it doesn't feel like so).
                    I experience (a few) bugs in KDE Plasma 5.14, Deepin 15.18 and a few more pieces of software. Guess I should all call them "unstable" from now on.

                    Comment


                    • #20
                      Originally posted by caligula View Post

                      Well, I've been using 4.19.0 for 18 days 24/7 and 4.19.2 for 14 days now without any corruption. The system has 3 x ext4 partitions and 5 x btrfs. Seems to work just fine..
                      Doesn't matter, if he says it's unstable, it's unstable ;-)

                      Comment

                      Working...
                      X