Announcement

Collapse
No announcement yet.

A Proposal To Change The Default I/O Scheduler

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

  • A Proposal To Change The Default I/O Scheduler

    Phoronix: A Proposal To Change The Default I/O Scheduler

    A patch was volleyed into the Linux kernel development camp to change the default I/O scheduler for non-SATA disk drives...

    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
    Sounds good

    Sounds good to me.
    CFQ shouldn't be used for PCI Express storage devices. It should be either deadline or noop.

    I love my SSD <3

    Comment


    • #3
      I wonder if IO-scheduler should be a mount option.

      Comment


      • #4
        Can't the two schedulers coexist in some way? I'm ignorant about that, but it obviously would be the better solution, because penalizing HDD users (which are more than SSD users, not only in the desktop market) sounds like a bad idea.

        Comment


        • #5
          This will be only for non-SATA drives (pci-e SSD, etc.), so most rotating media should be unaffected.

          Shouldn't it say non-ATA, though? That should also exclude SATA, though I guess they could want to include ATA for some reason....
          Last edited by Nobu; 10 April 2012, 07:27 PM. Reason: Added link for example

          Comment


          • #6
            Is the IO scheduler defined on build time or mount time (or any other criteria I can't think about)? How do I change it if it's not defined at build time?

            Comment


            • #7
              Originally posted by russofris View Post
              I wonder if IO-scheduler should be a mount option.
              No, because it is not a feature at the file-system level, also I would imagine the kernel only creates a per-disk queue, rather than a per-partition queue. If it were a mount option, you could get conflicts about what block on the device the kernel should access next. (It would require you write a scheduler to schedule each schedulers access to the block device, which is messy to say the least)

              Originally posted by mrugiero View Post
              Is the IO scheduler defined on build time or mount time (or any other criteria I can't think about)? How do I change it if it's not defined at build time?
              There is a sysFS interface for per-disk schedulers.

              echo the name of the scheduler you want into

              /sys/block/sd<X>/queue/scheduler

              i.e...
              echo "cfq" > /sys/block/sdb/queue/scheduler

              (running cat on that file will tell you the current selection and all valid options)

              Make it permanent by adding it to you local level rc or init file.

              You can set your default block device scheduler when configuring a custom kernel, or by passing a boot option.

              There first is permenant by itself, the second requires editing the grub defaults file.
              Last edited by WorBlux; 10 April 2012, 08:00 PM.

              Comment


              • #8
                Thanks a lot, WorBlux.

                Comment


                • #9
                  Why not bfq?

                  I have to say that cfq io scheduler has become a little bit slower in latest kernel compared to previous releases (using ata rotational disk).

                  Only recently I discovered bfq io scheduler, and i have to say it gives a nice boost to latency.

                  Why not planning a benchmark on most used io scheduler (cfq, deadline, bfq) on different disks (sata, ssd, raid..)?

                  Comment


                  • #10
                    Thanks for the explanation WorBlux! So there aren't problems in changing scheduler, good news for everybody uses a PCI-E SSD (and maybe also a SATA SSD, changing the scheduler through modification of init file).

                    Comment

                    Working...
                    X