Announcement

Collapse
No announcement yet.

Linux 5.0 I/O Scheduler Benchmarks On Laptop & Desktop Hardware

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

  • #11
    What's that about Flexible I/O Tester combining Linux AIO with "Buffered: Yes"? I thought Linux AIO only worked with O_DIRECT, or was that changed?

    Or maybe it's referring to user-space buffering in the app, itself?

    Comment


    • #12
      Originally posted by FireBurn View Post
      53 seconds to start xterm? That surely has to be a bug!
      Note that there's background I/O. Read the fine print. On a related note, the disk cache is probably devoid of most the needed files & filesystem metadata.

      Also, when I run strace xterm, I get 97 open() calls and 298 read()s. Most of those will be for ordinary files. When reading from a filesystem, an open() would typically translate into several I/O reads, as the kernel walks the filesystem datastructures, reads metadata, etc. read()s could translate in to more or less than 1:1, depending on their size, their relative locations, and whether the kernel is prefetching.

      So, I'd agree that it's pretty appalling, but not inconceivable.

      Comment


      • #13
        I used to toy around with scheduler with my old crappy laptop, now I've a powerful quadcore + SSD so I've stopped playing with optimisation. Which scheduler is the best for scenarios?
        1- laptop SSD only for everything
        Low everyday use, wifi, simple web surfing, using terminals, pure text editor, rare gaming

        2- desktop SSD for OS + HDD for data + HDD for games
        Gaming, Netflix/Amazon Prime Video, YouTube, web surfing.

        I don't think I do anything heavy, like video/photo editing.

        Comment


        • #14
          Gosh, these unbelievably high start-up times with BFQ, when there are writes in the background, mean only one thing: something broke for BFQ in 5.0. I have just reproduced this failure, and, as usual, I'll fix it with a little of luck. The problem is that you guys will see my fix probably only from 5.2 on ... I'm sorry about that.

          Comment


          • #15
            Originally posted by Buntolo View Post
            I used to toy around with scheduler with my old crappy laptop, now I've a powerful quadcore + SSD so I've stopped playing with optimisation. Which scheduler is the best for scenarios?
            1- laptop SSD only for everything
            Low everyday use, wifi, simple web surfing, using terminals, pure text editor, rare gaming

            2- desktop SSD for OS + HDD for data + HDD for games
            Gaming, Netflix/Amazon Prime Video, YouTube, web surfing.

            I don't think I do anything heavy, like video/photo editing.
            On my desktop, also a SATA SSD + HDD combo, I use "none" for the SSD and "mq-deadline" for my HDDs. Works well enough and system remains responsive even with heavy i/o load (something I could not say with Ubuntu's default cfq). Problem is with USB HDDs. Sometimes I get lags and hangs when I try to browse folders with large amounts of images for example, or even worse, after doing large transfers to my USB drives the desktop sort of locks up the drive and does not let me remove it gracefully. I tried other mq schedulers, but they all have similar issues with USB HDDs.

            Comment


            • #16
              Originally posted by paolo View Post
              Gosh, these unbelievably high start-up times with BFQ, when there are writes in the background, mean only one thing: something broke for BFQ in 5.0. I have just reproduced this failure, and, as usual, I'll fix it with a little of luck. The problem is that you guys will see my fix probably only from 5.2 on ... I'm sorry about that.
              Ok, I found the cause of this failure on my hw, and I fixed it. The commit is already publicly available for my dev version of bfq, here:


              I'll submit this fix/improvement soon for mainline. It'll probably be available only from 5.2 on.

              Next Phoronix tests will tell us whether I fully solved the problem, or there is still some other failures triggered by Michael's hardware.

              Comment


              • #17
                Originally posted by paolo View Post

                Ok, I found the cause of this failure on my hw, and I fixed it. The commit is already publicly available for my dev version of bfq, here:


                I'll submit this fix/improvement soon for mainline. It'll probably be available only from 5.2 on.

                Next Phoronix tests will tell us whether I fully solved the problem, or there is still some other failures triggered by Michael's hardware.
                I'm giving you 100 internet points. Why only for 5.2 and not 5.1? Is 5.1 already in feature freeze? I can't find any info.

                Comment


                • #18
                  Originally posted by Buntolo View Post

                  I'm giving you 100 internet points. Why only for 5.2 and not 5.1? Is 5.1 already in feature freeze? I can't find any info.
                  Thanks for the points!

                  Unfortunately, Jens (the block-layer maintainer) wants new patches by the -rc6 or -rc7 of the previous kernel version ... Here's, e.g., the outcome of a late submission of mine:

                  Comment


                  • #19
                    Originally posted by paolo View Post

                    Thanks for the points!

                    Unfortunately, Jens (the block-layer maintainer) wants new patches by the -rc6 or -rc7 of the previous kernel version ... Here's, e.g., the outcome of a late submission of mine:
                    https://lkml.org/lkml/2018/8/16/624
                    I'd say it's for stability reasons. Isn't 5.2 basically 4.24?

                    Comment

                    Working...
                    X