Skip to main content
Engineering LibreTexts

04-F.13.1: Storage Issues - IO Scheduling

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Linux I/O schedulers

    I/O schedulers attempt to improve throughput by reordering request access into a linear order based on the logical addresses of the data and trying to group these together. While this may increase overall throughput it may lead to some I/O requests waiting for too long, causing latency issues. I/O schedulers attempt to balance the need for high throughput while trying to fairly share I/O requests amongst processes.

    Different approaches have been taken for various I/O schedulers and each has their own set of strengths and weaknesses; the general rule is that there is no perfect default I/O scheduler for all the range of I/O demands a system may experience.

    Multiqueue I/O schedulers

    Note: These are the only I/O schedulers available in certain distributions of Linux as they are supported in the Linux 5.3 kernel.

    The following I/O schedulers are designed for multiqueue devices. These map I/O requests to multiple queues, and are handled by kernel threads that are distributed across multiple CPUs.

    bfq (Budget Fair Queuing) (Multiqueue)

    Designed to provide good interactive response, especially for slower I/O devices. This is a complex I/O scheduler and has a relatively high per-operation overhead so it is not ideal for devices with slow CPUs or high throughput I/O devices. Fair sharing is based on the number of sectors requested and heuristics rather than a time slice. Desktop users may like to experiment with this I/O scheduler as it can be advantageous when loading large applications.

    kyber (Multiqueue)

    Designed for fast multi-queue devices and is relatively simple. Has two request queues:

    • Synchronous requests (e.g. blocked reads)
    • Asynchronous requests (e.g. writes)

    There are strict limits on the number of request operations sent to the queues. In theory this limits the time waiting for requests to be dispatched, and hence should provide quick completion time for requests that are high priority.

    none (Multiqueue)

    The multi-queue no-op I/O scheduler. Does no reordering of requests, minimal overhead. Ideal for fast random I/O devices such as NVME.

    mq-deadline (Multiqueue)

    This is an adaption of the deadline I/O scheduler but designed for Multiqueue devices. A good all-rounder with fairly low CPU overhead.

    Non-multiqueue I/O schedulers

    NOTE: Non-multiqueue have been deprecated in some distributions of Linux onwards as they are no longer supported in the Linux 5.3 kernel.


    This fixes starvation issues seen in other schedulers. It uses 3 queues for I/O requests:

    • Sorted
    • Read FIFO - read requests stored chronologically
    • Write FIFO - write requests stored chronologically

    Requests are issued from the sorted queue unless a read from the head of a read or write FIFO expires. Read requests are preferred over write requests. Read requests have a 500ms expiration time, write requests have a 5s expiration time.

    cfq (Completely Fair Queuing)

    • Per-process sorted queues for synchronous I/O requests.
    • Fewer queues for asynchronous I/O requests.
    • Priorities from ionice are taken into account.

    Each queue is allocated a time slice for fair queuing. There may be wasteful idle time if a time slice quantum has not expired.

    noop (No-operation)

    Performs merging of I/O requests but no sorting. Good for random access devices (flash, ramdisk, etc) and for devices that sort I/O requests such as advanced storage controllers.

    Adapted from:
    "IOSchedulers" by Colin Ian King, Ubuntu Wiki is licensed under CC BY-SA 3.0

    04-F.13.1: Storage Issues - IO Scheduling is shared under a CC BY-SA 4.0 license and was authored, remixed, and/or curated by LibreTexts.

    • Was this article helpful?