Announcement

Collapse
No announcement yet.

Linux 4.9 I/O Scheduler Benchmarks On A SSD: Noop vs. CFQ vs. Deadline

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

  • #11
    Originally posted by xevrem View Post

    Not quite. The push now from the I/O scheduler folks is how to keep throughput high while minimizing impact to responsiveness. BFQ typically wins this use-case, but wont beat CFQ for raw throughput, but then that isnt the point of BFQ.
    blk-mq and BFQ are different things. There should be added for completness.

    Comment


    • #12
      I don't believe the 850 EVO was ever affected. Afaik it was only 840. And even if it were, wasn't it a kernel bug that was fixed shortly after discovery?

      Here's the kernel fix https://www.spinics.net/lists/raid/msg49440.html

      Actually looks like the Evo 850 was blacklisted too, but with the fix in place i think queued trim is safe to use?

      Comment


      • #13
        A lot of SSDs have queued trim blacklisted because it did not get used in windows. And for that reason a lot of implementation where broken. Like in "destroying all your data" broken!

        Comment


        • #14
          I also remember that it turned out most SSD vendors were doing it right and the Linux kernel was performing a horrible, horrible bug with TRIM. And that it got fixed.

          http://www.spinics.net/lists/raid/msg49440.html
          Last edited by Zan Lynx; 25 October 2016, 05:07 PM. Reason: Add link to Linux patch

          Comment


          • #15
            This benchmark isn't useful without BFQ.

            Comment


            • #16
              Originally posted by xevrem View Post

              Not quite. The push now from the I/O scheduler folks is how to keep throughput high while minimizing impact to responsiveness. BFQ typically wins this use-case, but wont beat CFQ for raw throughput, but then that isnt the point of BFQ.
              BFQ is from looking at tests done and real world usage is snake oil. BFQ does not win any nor have any positive affect on desktop interactive responsiveness.

              Comment


              • #17
                Interesting benchmarks.
                But all I see are a screwed up I/O subsystem. I can't find a normal reason where CFQ would be faster than NO-OP on a non-rotational media with a single user/thread case. The whole point has to be to trade bandwidth for I/O latency. The same goes for CFQ. It looses so badly to NO-OP in another single user/thread case I have to wonder wth it's actually doing...

                Comment


                • #18
                  Originally posted by milkylainen View Post
                  Interesting benchmarks.
                  But all I see are a screwed up I/O subsystem. I can't find a normal reason where CFQ would be faster than NO-OP on a non-rotational media with a single user/thread case. The whole point has to be to trade bandwidth for I/O latency. The same goes for CFQ. It looses so badly to NO-OP in another single user/thread case I have to wonder wth it's actually doing...
                  A lot of context switching?

                  Comment


                  • #19
                    Originally posted by Rallos Zek View Post
                    BFQ is from looking at tests done and real world usage is snake oil. BFQ does not win any nor have any positive affect on desktop interactive responsiveness.
                    References? Have you ever used it, or even seen/read the tests done? That must be why many distributions use it by default, out-of-tree. Speaking of the latter, its been submitted to LKML today (and there are references):
                    https://lkml.org/lkml/2016/10/26/218

                    Comment


                    • #20
                      Originally posted by jwh7 View Post
                      References? Have you ever used it, or even seen/read the tests done? That must be why many distributions use it by default, out-of-tree. Speaking of the latter, its been submitted to LKML today (and there are references):
                      https://lkml.org/lkml/2016/10/26/218
                      thank you. the fact that its been submitted to mainline kernel was a pleasant way to start my day . I am a longtime user of BFQ and can confirm its validity. Its an amazing scheduler. High throughput high response times. In fact, it performs better than blk-mq for rotating media.

                      Comment

                      Working...
                      X