Announcement

Collapse
No announcement yet.

Linux 5.0 HDD I/O Scheduler Benchmarks - BFQ Takes The Cake

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

  • #11
    There is one more thing I would love to see benchmarked, which is performance under heavy swapping.

    Currently, my single worst pain point has been this one. Even whith 8GB of swap, there will always be an application (Firefox, for instance), or a game (Planetary Anihilation was horrible when I had this amount of RAM) that triggers swapping, and makes the whole desktop irresponsive.

    Luckily there's the SysRq for OOM kill, that I end up using several times a day, especially on memory-constrained devices. Ptherwise it isn't viable to wait for more than half an hour for getty to show up, then even more for zsh to start... (same problem via ssh). I'm not sure whether BFQ helps in this situation, I'd have to try out. In any case, I recommend compressed memory over HDD-based swap.

    The second pain point was still related to heavy disk I/O, during which the various desktop environments usually slow down to the point where I can't move my mouse at all. For instance, I have a live Arch Linux stick, and it's completely unresponsive during updates. I should try BFQ again in that case.

    Outside of these two terrible areas, Linux on the desktop has been a pretty smooth ride for me

    Comment


    • #12
      Originally posted by tomtomme View Post

      yep, thats what I've tried above, but his result is something else. I also tried converting in percentages roughly, but thats not it either... and seeing very high geometric means on other benchmarks like this: https://www.phoronix.com/scan.php?pa...meltdown&num=1
      he does not seem to go the % way.
      According to the code, all results for "lower is better" are incorporated as their reciprocal value, so in general this is correct.

      What is totally intransparent is, the mean value is not calculated based on the values published in the article, but on **all** results (see the "raw" benchmark values).

      This also leads to some "interesting" effects. Consider two benchmarks A and B, where A has e.g. 2 subbenchmarks (CPUs, block sizes, TCP/UDP, whatever) while B has only 1. If candidate 1 scores twice as good as 2 in A and candidate 2 scores twice as good in B, candidate 1 will be the clear winner - pow(2 * 2 * 0.5, 1/3) = 1.26. By "appropriate" choice of benchmarks, you can force the geometric mean to resemble mostly one scenario.

      Also, the geometric mean then also contains even obvious outliers - check the values from the recent 10GBit/s network benchmarks:
      https://openbenchmarking.org/result/...SP-1901152SP62
      Have a look at the "Ethr" TCP connections/s results - there are two results, where the deviation is almost as large as the mean value, and 3 times as large as the mean for any other candidate. Clear sign of a broken benchmark setup.

      Comment


      • #13
        The Linux kernel 5.1 branch actually contains even more BFQ optimizations, so it would be interesting to see how that performs.

        Comment


        • #14
          Originally posted by [email protected] View Post
          There is one more thing I would love to see benchmarked, which is performance under heavy swapping.

          Currently, my single worst pain point has been this one. Even whith 8GB of swap, there will always be an application (Firefox, for instance), or a game (Planetary Anihilation was horrible when I had this amount of RAM) that triggers swapping, and makes the whole desktop irresponsive.

          Luckily there's the SysRq for OOM kill, that I end up using several times a day, especially on memory-constrained devices. Ptherwise it isn't viable to wait for more than half an hour for getty to show up, then even more for zsh to start... (same problem via ssh). I'm not sure whether BFQ helps in this situation, I'd have to try out. In any case, I recommend compressed memory over HDD-based swap.

          The second pain point was still related to heavy disk I/O, during which the various desktop environments usually slow down to the point where I can't move my mouse at all. For instance, I have a live Arch Linux stick, and it's completely unresponsive during updates. I should try BFQ again in that case.

          Outside of these two terrible areas, Linux on the desktop has been a pretty smooth ride for me
          Sorry, but who use swap in these times (maybe apart from _big_ iron)? - Ten years ago or even around 1993 as I started using and _developing_ Linux, but today? Use SSDs as much as you can. And starting with Linux kernel 2.4 (devel) then 2.5/2.6 we had GREAT preemptive stuff which made desktops mostly smooth.

          Comment


          • #15
            How could I test bfq low latency? "sudo echo bfq > /sys/block/sda/queue/scheduler " not working for me

            Comment


            • #16
              Originally posted by braulio_holtz View Post
              How could I test bfq low latency? "sudo echo bfq > /sys/block/sda/queue/scheduler " not working for me
              Need to enable blk-mq schedulers first. See this https://unix.stackexchange.com/quest...heduler/376136

              Comment


              • #17
                Originally posted by starshipeleven View Post
                Need to enable blk-mq schedulers first. See this https://unix.stackexchange.com/quest...heduler/376136
                And make sure you have the right module (bfq / CONFIG_IOSCHED_BFQ=m / CONFIG_BFQ_GROUP_IOSCHED=y) available or compiled.

                Comment


                • #18
                  Originally posted by braulio_holtz View Post
                  How could I test bfq low latency? "sudo echo bfq > /sys/block/sda/queue/scheduler " not working for me
                  That command never will work because it runs "echo" as root but redirects it into the scheduler file as your user ID. Which doesn't have permission.

                  What you want is something like "echo bfq | sudo tee /sys/block/sda/queue/scheduler"

                  Comment


                  • #19
                    Originally posted by nuetzel View Post

                    Sorry, but who use swap in these times (maybe apart from _big_ iron)? - Ten years ago or even around 1993 as I started using and _developing_ Linux, but today? Use SSDs as much as you can. And starting with Linux kernel 2.4 (devel) then 2.5/2.6 we had GREAT preemptive stuff which made desktops mostly smooth.
                    I think that everyone should use swap, even if only compressed memory. In my experience, performance under memory pressure is even worse (I believe the stack is evicted from memory, and read from disk instead) if there is none. And with a well-sized computer, you might use ~50% of the RAM on average, but there's always the outlier task, or the odd program with a memory leak, and that shouldn't bring your system down.

                    Unfortunately, as much as I would like to use SSDs, they are still impractical in many cases. I don't use one in my main computer, but it is also to make me aware of the shortcomings of the software I use. Many embedded platforms cannot afford the luxury of SSDs, or a lot of memory, so I also had some swapping issues there. And lastly, that doesn't help with my live USB stick example. That said, I am planning to upgrade to one at some point, just like I did with my memory (8 -> 16GB when the prices started to decrease, yet I still need some swap from time to time).

                    Please, don't assume that just because you didn't experience the need for it, it isn't needed. It is, and I found a couple issues with the current implementation. I also experienced the same problem on multiple servers, as well as company and university-issued computers, friend's laptops, multiple desktops. I don't think it is just me.

                    But really, I think these two issues are interlinked. It is as if when writing/reading, big buffers are allocated, and fill up all the available memory space, so that when I/O speed is low, there is no more memory to read data from disk into, as the buffers have to be written back before. There might also be an issue with timestamps and cache eviction, as data has to wait a fair bit before being put into memory, which might make it more likely to be evicted? I'd have to dig into the code to find answers to this, this is just a possible explanation I came up with, based on the symptoms.

                    Unfortunately, it might be quite difficult to come up with a nice benchmark. I'll see if I can come up with one in a VM where I throttle I/O and memory.

                    Comment


                    • #20
                      Can anyone tell me, with some certainty, which is the best scheduler to use for a development machine with either a SATA SSD or an NVME SSD? It seems to change every time a new set of benchmarks comes out. Right now I just set it to 'None'. is there something better??

                      Comment

                      Working...
                      X